From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzFic-0000hR-2k for qemu-devel@nongnu.org; Mon, 03 Dec 2007 13:08:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzFiX-0000g0-7s for qemu-devel@nongnu.org; Mon, 03 Dec 2007 13:08:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzFiX-0000fu-34 for qemu-devel@nongnu.org; Mon, 03 Dec 2007 13:08:29 -0500 Received: from nz-out-0506.google.com ([64.233.162.225]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IzFiW-0007uQ-9K for qemu-devel@nongnu.org; Mon, 03 Dec 2007 13:08:28 -0500 Received: by nz-out-0506.google.com with SMTP id f1so8296685nzc for ; Mon, 03 Dec 2007 10:08:27 -0800 (PST) Message-ID: <47544613.3050309@codemonkey.ws> Date: Mon, 03 Dec 2007 12:08:19 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O References: <11966765602186@bull.net> <475426C7.20503@codemonkey.ws> <20071203170800.GC3797@implementation> <200712031717.24596.paul@codesourcery.com> <20071203174931.GA13614@shareable.org> In-Reply-To: <20071203174931.GA13614@shareable.org> 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: Samuel Thibault Jamie Lokier wrote: > Paul Brook wrote: > >> On Monday 03 December 2007, Samuel Thibault wrote: >> >>> Anthony Liguori, le Mon 03 Dec 2007 09:54:47 -0600, a écrit : >>> >>>> Have you done any performance testing? Buffered IO should absolutely >>>> beat direct IO simply because buffered IO allows writes to complete >>>> before they actually hit disk. >>>> >>> Since qemu can use the aio interface, that shouldn't matter. >>> >> Only if the emulated hardware and guest OS support multiple concurrent >> commands. IDE supports async operation, but not concurrent commmands. In >> practice this means you only get full performance if you're using the SCSI >> emulation. >> > > With the IDE emulation, when the emulated "disk write cache" flag is > on it may be reasonable to report a write as completed when the AIO is > dispatched, without waiting for the AIO to complete. > > An IDE flush cache command would wait for all outstanding write AIOs > to complete, and then issue a flush cache (fdatasync) to the real > device before reporting it has completed. > > That's roughly equivalent to what an IDE disk with write caching does, > and it would provide exactly the guarantees for safe storage to the > real physical medium that a journalling filesystem or database in the > guest requires. > > If a guest doesn't use journalling with IDE write cache safely > (e.g. 2.4 Linux and earler), it can simply turn off the IDE "disk > write cache" flag, which is what it has to do on a real physical disk > too. > > Terminating the qemu process abruptly might cancel some AIOs, but even > that is ok, as it's equivalent to pulling the power on a real disk > with uncommitted cached writes. > Except that in an enterprise environment, you typically have battery backed disk cache. It really doesn't matter though b/c in QEMU today, submitting the request blocks until it's completed anyway (which is nearly instant anyway since I/O is buffered). Regards, Anthony Liguori > -- Jamie > > > >