From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLD3f-0008H6-91 for qemu-devel@nongnu.org; Wed, 05 Mar 2014 09:44:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLD3W-0003St-Dq for qemu-devel@nongnu.org; Wed, 05 Mar 2014 09:44:31 -0500 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:35352 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLD3W-0003ST-3J for qemu-devel@nongnu.org; Wed, 05 Mar 2014 09:44:22 -0500 Message-ID: <53173841.1020905@kamp.de> Date: Wed, 05 Mar 2014 15:44:17 +0100 From: Peter Lieven MIME-Version: 1.0 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> <20140304092456.GF25676@stefanha-thinkpad.redhat.com> In-Reply-To: <20140304092456.GF25676@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: Kevin Wolf , Paolo Bonzini , "qemu-devel@nongnu.org" , Stefan Hajnoczi 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