From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IxONU-0001ns-S6 for qemu-devel@nongnu.org; Wed, 28 Nov 2007 09:59:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IxONT-0001nc-Fk for qemu-devel@nongnu.org; Wed, 28 Nov 2007 09:59:04 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IxONT-0001nX-59 for qemu-devel@nongnu.org; Wed, 28 Nov 2007 09:59:03 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IxONT-0007RF-15 for qemu-devel@nongnu.org; Wed, 28 Nov 2007 09:59:03 -0500 Received: by rv-out-0910.google.com with SMTP id g11so4377469rvb for ; Wed, 28 Nov 2007 06:59:00 -0800 (PST) Message-ID: <474D8232.5070802@codemonkey.ws> Date: Wed, 28 Nov 2007 08:58:58 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] Open disk images with O_DIRECT References: <11962585701617@bull.net> <20071128142739.GA7379@redhat.com> <20071128143402.GG4083@implementation.uk.xensource.com> In-Reply-To: <20071128143402.GG4083@implementation.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Laurent Vivier Samuel Thibault wrote: > Daniel P. Berrange, le Wed 28 Nov 2007 14:27:39 +0000, a écrit : > >> On Wed, Nov 28, 2007 at 03:02:50PM +0100, Laurent Vivier wrote: >> >>> These patches allow to open file using O_DIRECT and bypass the host I/O cache. >>> >>> [PATCH 1/2] Add "directio" parameter to "-drive" >>> >>> Using "directio=on" with "-drive" will open the disk image >>> file using "O_DIRECT". >>> >> I don't see the point in adding a config param for this. If it provides a >> useful performance improvement (or other benefit) we should enable it by >> default all the time. >> > > That depends on the mileage of the user. Sometimes it is useful since > it avoids the duplication of page or buffer cache between the guest and > the host, sometimes it is not because the guest is not so i/o friendly > and hence using the host page/buffer cache is useful. > In the very least, I think it should be named something more along the lines of "caching=off" or "buffering=off" since that's closer to what the hardware concept is without exposing implementation details to the user. Regards, Anthony Liguori > Samuel > > > >