[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive

From: Aurelien Jarno
Subject: Re: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive
Date: Wed, 26 May 2010 17:40:35 +0200
User-agent: Mozilla-Thunderbird (X11/20090707)

Anthony Liguori a écrit :
> On 05/26/2010 09:12 AM, Aurelien Jarno wrote:
>>> It's hard for me to consider this a performance regression because
>>> ultimately, you're getting greater than bare metal performance (because
>>> of extremely aggressive caching).  It might be a regression from the
>>> previous performance, but that was at the cost of safety.
>> For people who don't care about safety it's still a regression. And it
>> is a common usage of QEMU.
> It's not a functional change.  It's a change in performance.  There are 
> tons of changes in performance characteristics of qemu from version to 
> version.  It's not even a massive one.
>>> We might get 100 bug reports about this "regression" but they concern
>>> much less than 1 bug report of image corruption because of power
>>> failure/host crash.  A reputation of being unsafe is very difficult to
>>> get rid of and is something that I hear concerns about frequently.
>>> I'm not suggesting that the compile option should be disabled by default
>>> upstream.  But the option should be there for distributions because I
>>> hope that any enterprise distro disables it.
>> Which basically means those distro don't care about some use cases of
>> QEMU, that were for most of them the original uses cases. It's sad.
> This isn't a feature.  This is a change in performance.  No one is not 
> able to satisfy their use case from this behavior.
>> Sometimes I really whishes that KVM never tried to reintegrate code into
>> QEMU, it doesn't bring only good things.
> I highly doubt that this is even visible on benchmarks without using 
> KVM.  The improvement on a microbenchmark was relatively small and the 
> cost from TCG would almost certainly dwarf it.

It is something clearly visible. Before fsync() was not used, and it
happens this syscall can be very expensive (ie a few seconds, especially
with some other i/o load on the system) on ext3 with not so old kernels.
A google search for "firefox fsync" will give you a few pointers.

> Also, remember before KVM, we had single threaded IO and posix-aio 
> (which is still single threaded).  If KVM never happened, block 
> performance would be far, far worse than it is today with cache=writeback.

io thread is not enable by default in QEMU.

Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net

reply via email to

[Prev in Thread] Current Thread [Next in Thread]