From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KoIcm-0001EU-7i
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:05:48 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KoIck-0001Cv-Gm
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:05:47 -0400
Received: from [199.232.76.173] (port=54129 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KoIck-0001Cf-9T
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:05:46 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:45944)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1KoIcj-0006yS-P0
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:05:46 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
Date: Fri, 10 Oct 2008 15:05:41 +0100
References: <48EE38B9.2050106@codemonkey.ws>
	<200810101353.32933.paul@codesourcery.com>
	<48EF5EC0.1020809@codemonkey.ws>
In-Reply-To: <48EF5EC0.1020809@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200810101505.42382.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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, kvm-devel <kvm-devel@lists.sourceforge.net>, Laurent Vivier <Laurent.Vivier@bull.net>, qemu-devel@nongnu.org, Ryan Harper <ryanh@us.ibm.com>

On Friday 10 October 2008, Anthony Liguori wrote:
> Paul Brook wrote:
> >> But that said, I'm concerned that this is far too confusing for users.
> >> I don't think anyone is relying on disk write performance when in
> >> write-back mode simply because the guest already has a page cache so
> >> writes are already being completed instantaneously from the
> >> application's perspective.
> >
> > This isn't entirely true. With IDE devices you don't have command
> > queueing, so it's easy for a large write to stall subsequent reads for a
> > relatively long time.
> > I'm not sure how much this effects qemu, but I've definitely seen it
> > happening on real hardware.
>
> I think that suggests we should have a cache=wb option and if people
> report slow downs with IDE, we can observe if cache=wb helps.  My
> suspicion is that it's not going to have a practical impact because as
> long as the operations are asynchronous (via DMA), then you're getting
> native-like performance.

Sounds reasonable to me.

Paul