From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KoISe-0004KD-Na
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 09:55:20 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KoISc-0004Ij-Bg
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 09:55:19 -0400
Received: from [199.232.76.173] (port=36910 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KoISc-0004Ig-10
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 09:55:18 -0400
Received: from wx-out-0506.google.com ([66.249.82.224]:5831)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1KoISb-000453-I3
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 09:55:17 -0400
Received: by wx-out-0506.google.com with SMTP id h27so247501wxd.4
	for <qemu-devel@nongnu.org>; Fri, 10 Oct 2008 06:55:16 -0700 (PDT)
Message-ID: <48EF5EC0.1020809@codemonkey.ws>
Date: Fri, 10 Oct 2008 08:55:12 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
References: <48EE38B9.2050106@codemonkey.ws>
	<20081010081157.GA13431@volta.aurel32.net>
	<48EF49D8.3090002@codemonkey.ws>
	<200810101353.32933.paul@codesourcery.com>
In-Reply-To: <200810101353.32933.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
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: Paul Brook <paul@codesourcery.com>
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>

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.

My bigger concern is synchronous IO operations because then a guest VCPU 
is getting far less time to run and that may have a cascading effect on 
performance.

Anyway, I'll work up a new patch with cache=wb and repost.

Regards,

Anthony Liguori

> Paul
>