[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush
Date: Mon, 10 May 2010 17:12:48 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 05/10/2010 05:03 PM, Alexander Graf wrote:
On 10.05.2010, at 23:59, Anthony Liguori wrote:

On 05/10/2010 04:51 PM, Alexander Graf wrote:
Thanks to recent improvements, qemu flushes guest data to disk when the guest
tells us to do so.

This is great if we care about data consistency on host disk failures. In cases
where we don't it just creates additional overhead for no net win. One such use
case is the building of appliances in SUSE Studio. We write the resulting images
out of the build VM, but compress it directly afterwards. So if possible we'd
love to keep it in RAM.

This patchset introduces a new block parameter to -drive called "flush" which
allows a user to disable flushing in odd scenarios like the above. To show the
difference in performance this makes, I have put together a small test case.
Inside the initrd, I call the following piece of code on a 500MB preallocated
vmdk image:

This seems like it's asking for trouble to me.  I'm not sure it's worth the 
minor performance gain.
The gain is little on my netbook where I did the test on. This is part of 
performance regressions from 0.10 to 0.12 where we're talking build times of 2 
minutes going to 30. While writeback was most of the chunk, flushing still at 
least doubled the build times which is unacceptable for us.

There's got to be a better place to fix this. Disable barriers in your guests?


Anthony Liguori

I also fail to see where it's asking for trouble. If we don't flush volatile 
data, things are good, no?


reply via email to

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