From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1G6rj5-0004NG-Fd
	for qemu-devel@nongnu.org; Sat, 29 Jul 2006 12:31:43 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1G6rj2-0004Ms-1w
	for qemu-devel@nongnu.org; Sat, 29 Jul 2006 12:31:43 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1G6rj1-0004Mp-T7
	for qemu-devel@nongnu.org; Sat, 29 Jul 2006 12:31:39 -0400
Received: from [65.74.133.4] (helo=mail.codesourcery.com)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G6rlH-0000fL-51
	for qemu-devel@nongnu.org; Sat, 29 Jul 2006 12:33:59 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk
Date: Sat, 29 Jul 2006 17:31:36 +0100
References: <44CA6B76.7000004@redhat.com>
	<200607291704.45217.paul@codesourcery.com>
	<44CB8B35.5090405@redhat.com>
In-Reply-To: <44CB8B35.5090405@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200607291731.36528.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Rik van Riel <riel@redhat.com>
Cc: qemu-devel@nongnu.org

> 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.

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.

Paul