From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7Rsp-0007DG-VN for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7Rso-0007CP-A7 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:11 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7Rso-0007CK-5e for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:10 -0400 Received: from [195.184.98.160] (helo=virtualhost.dk) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1G7RvP-0004Lx-S5 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:10:52 -0400 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1G7Rsn-00026N-00 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 09:08:09 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.51) id 1G7Rsl-00010L-JG for qemu-devel@nongnu.org; Mon, 31 Jul 2006 09:08:07 +0200 Date: Mon, 31 Jul 2006 09:08:32 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk Message-ID: <20060731070832.GE14748@suse.de> References: <44CA6B76.7000004@redhat.com> <200607291704.45217.paul@codesourcery.com> <44CB8B35.5090405@redhat.com> <200607291731.36528.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607291731.36528.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 On Sat, Jul 29 2006, Paul Brook wrote: > > Easy to do with the fsync infrastructure, but probably not worth > > doing since people are working on the AIO I/O backend, which would > > allow multiple outstanding writes from a guest. That, in turn, > > means I/O completion in the guest can be done when the data really > > hits disk, but without a performance impact. > > Not entirely true. That only works if you allow multiple guest IO > requests in parallel, ie. some form of tagged command queueing. This > requires either improving the SCSI emulation, or implementing SATA > emulation. AFAIK parallel IDE doesn't support command queueing. Parallel IDE does support queuing, but it never gained wide spread support and the standard is quite broken as well (which is probably _why_ it never got much adoption). It was also quite suboptimal from a CPU efficiency POV. Besides, async completion in itself is not enough, QEMU still needs to honor ordered writes (barriers) and cache flushes. > My impression what that the initial AIO implementation is just > straight serial async operation. IO wouldn't actually go any faster, > it just means the guest can do something else while it's waiting. Depends on the app, if the io workload is parallel then you should see a nice speedup as well (as QEMU is then no longer the serializing bottle neck). -- Jens Axboe