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
