From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKlb3-0000BX-Fw for qemu-devel@nongnu.org; Tue, 04 Mar 2014 04:25:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKlau-0005N8-V2 for qemu-devel@nongnu.org; Tue, 04 Mar 2014 04:25:09 -0500 Received: from mail-ee0-x235.google.com ([2a00:1450:4013:c00::235]:48877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKlau-0005MI-Ni for qemu-devel@nongnu.org; Tue, 04 Mar 2014 04:25:00 -0500 Received: by mail-ee0-f53.google.com with SMTP id e51so3516859eek.40 for ; Tue, 04 Mar 2014 01:24:59 -0800 (PST) Date: Tue, 4 Mar 2014 10:24:56 +0100 From: Stefan Hajnoczi Message-ID: <20140304092456.GF25676@stefanha-thinkpad.redhat.com> References: <530DBE6C.5030502@kamp.de> <20140226154154.GB20820@stefanha-thinkpad.muc.redhat.com> <530E0FF0.20501@kamp.de> <20140227085711.GC21749@stefanha-thinkpad.redhat.com> <53109E99.3020102@kamp.de> <20140303120349.GA21055@stefanha-thinkpad.redhat.com> <53147385.2090906@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53147385.2090906@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: Kevin Wolf , Paolo Bonzini , "qemu-devel@nongnu.org" , 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. Stefan