Re: [Qemu-devel] qemu-img convert cache mode for source

[Peter Lieven <pl@kamp.de>]

Am 04.03.2014 10:24, schrieb Stefan Hajnoczi:
> On Mon, Mar 03, 2014 at 01:20:21PM +0100, Peter Lieven wrote:
>> On 03.03.2014 13:03, Stefan Hajnoczi wrote:
>>> So what is the actual performance problem you are trying to solve and
>>> what benchmark output are you getting when you compare with
>>> FADV_DONTNEED against without FADV_DONTNEED?
>> I found the performance to be identical. For the problem see below please.
>>> I think there's a danger that the discussion will go around in circles.
>>> Please post the performance results that kicked off this whole effort
>>> and let's focus on the data.  That way it's much easier to evaluate what
>>> changes to QEMU are a win and which are not necessary.
>> I found that under memory pressure situations the increasing buffers
>> leads to vserver memory being swapped out. This caused trouble
>> especially in overcommit scenarios (where all memory is backed by
>> swap).
> I think the general idea is qemu-img should not impact running guests,
> even on a heavily loaded machine.  But again, this needs to be discussed
> using concrete benchmarks with configurations and results posted to the
> list.
Sure, this is why I started to look at this. I found that under high memory
pressure a backup (local storage -> NFS) causes swapping. I started to
use libnfs as destination to avoid influence of the kernel NFS client. But
I saw that the buffers still increase while a backup is running. With the
proposed patch I sent recently

[PATCH] block: introduce BDRV_O_SEQUENTIAL

I don't see this behaviour while I have not yet observed a performance penalty.

Peter
>
> Stefan