From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLVkI-0008FD-WD for qemu-devel@nongnu.org; Thu, 06 Mar 2014 05:41:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLVkD-0006aH-Df for qemu-devel@nongnu.org; Thu, 06 Mar 2014 05:41:46 -0500 Received: from mail-ee0-x235.google.com ([2a00:1450:4013:c00::235]:54427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLVkD-0006aA-7P for qemu-devel@nongnu.org; Thu, 06 Mar 2014 05:41:41 -0500 Received: by mail-ee0-f53.google.com with SMTP id e51so1019731eek.40 for ; Thu, 06 Mar 2014 02:41:40 -0800 (PST) Date: Thu, 6 Mar 2014 11:41:37 +0100 From: Stefan Hajnoczi Message-ID: <20140306104137.GG23172@stefanha-thinkpad.redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53176849.10804@kamp.de> Subject: Re: [Qemu-devel] qemu-img convert cache mode for source List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Marcus , Kevin Wolf , "qemu-devel@nongnu.org" , Stefan Hajnoczi , Paolo Bonzini 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. 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