From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzFQN-0001d0-60 for qemu-devel@nongnu.org; Mon, 03 Dec 2007 12:49:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzFQI-0001WW-8I for qemu-devel@nongnu.org; Mon, 03 Dec 2007 12:49:42 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzFQI-0001WC-3F for qemu-devel@nongnu.org; Mon, 03 Dec 2007 12:49:38 -0500 Received: from mail2.shareable.org ([80.68.89.115]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IzFQH-0001xZ-OH for qemu-devel@nongnu.org; Mon, 03 Dec 2007 12:49:37 -0500 Date: Mon, 3 Dec 2007 17:49:31 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O Message-ID: <20071203174931.GA13614@shareable.org> References: <11966765602186@bull.net> <475426C7.20503@codemonkey.ws> <20071203170800.GC3797@implementation> <200712031717.24596.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200712031717.24596.paul@codesourcery.com> 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 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. -- Jamie