From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkxs0-0003M6-BS for qemu-devel@nongnu.org; Mon, 25 Nov 2013 10:14:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vkxru-0004YT-CF for qemu-devel@nongnu.org; Mon, 25 Nov 2013 10:14:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkxru-0004YP-3f for qemu-devel@nongnu.org; Mon, 25 Nov 2013 10:14:34 -0500 Message-ID: <52936951.3090602@redhat.com> Date: Mon, 25 Nov 2013 16:14:25 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1385387840-17307-1-git-send-email-pl@kamp.de> <1385387840-17307-4-git-send-email-pl@kamp.de> <529364B5.6000202@redhat.com> <529367C8.7080301@kamp.de> In-Reply-To: <529367C8.7080301@kamp.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1.8 3/6] qemu-img: add option to specify alternate iobuffer size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Il 25/11/2013 16:07, Peter Lieven ha scritto: >>> since the convert process is basically a sync operation it might >>> be benificial in some case to change the hardcoded I/O buffer >>> size to an alternate (greater) value. >> Do you really need the extra knob? You can just add to BlockLimits the >> optimal transfer length, and use it unconditionally. > If you say patch 5 and 3 are ok. What could be done is to remove > this knob and increase the iobuf_size to cluster_size if cluster_size > is greater. Yes, that makes sense because it avoids unnecessary COW. > I do not want to increase the default iobuf size to anything > greater than 2MB. I do not know why this was choosen, but maybe > there was a reason for it. I think it is fine to increase it to the cluster_size or even to the optimal transfer length (new BlockLimits field). > The storages we use here have a very strange page size of 15MB. > If I sent aligned 15MB chunks the performace is about +50% compared > to the original qemu-img. I think composing the optimal transfer length and optimal unmap granularity (cluster_size) will work well: * clamp maximum size to optimal transfer length * then, round final sector down to unmap granularity Paolo