qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Lieven
Subject: Re: [Qemu-devel] qemu-img convert cache mode for source
Date: Thu, 06 Mar 2014 19:58:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Am 06.03.2014 11:41, schrieb Stefan Hajnoczi:
> On Wed, Mar 05, 2014 at 07:09:13PM +0100, Peter Lieven wrote:
>> Am 05.03.2014 18:38, schrieb Marcus:
>>> On Wed, Mar 5, 2014 at 8:53 AM, Peter Lieven <address@hidden> wrote:
>>>> So you can confirm my oberservations and would be happy if
>>>> this behaviour could be toggled with a cmdline switch?
>>> Yes, I've seen the same behavior you mention just with 'cp'. It was
>>> with a version of the CentOS 6.2 kernel, at least, before we added
>>> FADV_DONTNEED into the backup scripts.
>> Ok, Stefan would you be happy with it?
> I'm happy with it.
>
> But I'm a little frustrated that I've asked multiple times for a
> concrete benchmark and it hasn't been provided.
I did not want to frustrate you with that. I thought my abstract
description of my observations in the commit message would be sufficient.
Especially when Marcus provided his observations.

I will try to setup a test case.

Peter
>
> In order to review patches that improve performance, we need a benchmark
> that can be reproduced.  And the commit description must include results
> that quantify the improvement.
>
> Otherwise it's too easy to merge patches that sound reasonable but don't
> have the effect that everyone thought they had.
>
> I see two possible benchmarks:
>
> 1. Create memory pressure so that a benchmark performs worse unless we
>    slim down our page cache usage.
>
> 2. Compare mm statistics before and after qemu-img to prove no longer
>    bloats the page cache.
>
> #2 doesn't prove that there is a practical performance issue, it just
> optimizes the mm statistics.  But at least it quantifies that and serves
> as a test case.
>
> Either would be okay.
>
> Stefan




reply via email to

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