From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLdVa-0003dc-C0 for qemu-devel@nongnu.org; Thu, 06 Mar 2014 13:59:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLdVU-0008O1-P7 for qemu-devel@nongnu.org; Thu, 06 Mar 2014 13:59:06 -0500 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:40755 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLdVU-0008N2-F7 for qemu-devel@nongnu.org; Thu, 06 Mar 2014 13:59:00 -0500 Message-ID: <5318C566.60109@kamp.de> Date: Thu, 06 Mar 2014 19:58:46 +0100 From: Peter Lieven MIME-Version: 1.0 References: <20140227085711.GC21749@stefanha-thinkpad.redhat.com> <53109E99.3020102@kamp.de> <20140303120349.GA21055@stefanha-thinkpad.redhat.com> <53147385.2090906@kamp.de> <20140304092456.GF25676@stefanha-thinkpad.redhat.com> <53173841.1020905@kamp.de> <53174877.90509@kamp.de> <53176849.10804@kamp.de> <20140306104137.GG23172@stefanha-thinkpad.redhat.com> In-Reply-To: <20140306104137.GG23172@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-img convert cache mode for source List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Marcus , Kevin Wolf , "qemu-devel@nongnu.org" , Stefan Hajnoczi , Paolo Bonzini 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 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