From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwT2E-0006U3-HN for qemu-devel@nongnu.org; Wed, 01 Aug 2012 03:07:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwT27-0001rt-R0 for qemu-devel@nongnu.org; Wed, 01 Aug 2012 03:07:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwT27-0001pK-J8 for qemu-devel@nongnu.org; Wed, 01 Aug 2012 03:07:51 -0400 Message-ID: <5018D5BF.4010805@redhat.com> Date: Wed, 01 Aug 2012 09:07:43 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <50181B34.4090007@redhat.com> <50181C16.8010009@redhat.com> <5018CD96.3080700@redhat.com> In-Reply-To: <5018CD96.3080700@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 2/4] block: add live block commit functionality List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: stefanha@gmail.com, jcody@redhat.com, Eric Blake , qemu-devel@nongnu.org, supriyak@linux.vnet.ibm.com Il 01/08/2012 08:32, Kevin Wolf ha scritto: >>>> >>> +enum { >>>> >>> + /* >>>> >>> + * Size of data buffer for populating the image file. This should be large >>>> >>> + * enough to process multiple clusters in a single call, so that populating >>>> >>> + * contiguous regions of the image is efficient. >>>> >>> + */ >>>> >>> + COMMIT_BUFFER_SIZE = 512 * 1024, /* in bytes */ >>>> >>> +}; >>> >> >>> >> Paolo's latest round of patches got to the point of making this >>> >> configurable for drive-mirror; is that something you should be copying here? >> > >> > Yes > Though its use is very limited for live commit. For the mirror it's > important because a larger number can mean that more data is > unnecessarily written, and the target can become larger than the source. Note that the latest version of mirroring has _two_ knobs: 1) granularity is what decides how much data could be written unnecessarily, because of the dirty bitmap. 2) buffer size is what decides how much I/O is in flight at one time. The default values are resp. the cluster size (or 64K for raw) and 10M. The two together give mirroring some self-tuning capability. For example in the first part of the mirroring you will likely proceed in 10M chunks with no concurrency; once you're synchronized, you'll probably send several chunks, perhaps all 64K if the guest does random writes. Live commit as it is done now doesn't need any of this complication; it is just a background operation that does not need to compete with the guest. So using a larger buffer is indeed always better, and 512K is a nice intermediate value between mirroring's 64K and 10M extremes. > For live commit, I think using a larger buffer is always better. > > Hm, part of the difference is that I assume that commit uses > bdrv_is_allocated() to check whether some data must really be copied. > But then, there's no reason why mirroring couldn't do that as well. Paolo? We copy a cluster at a time, and that's also the resolution of bdrv_is_allocated so we wouldn't gain anything. Nice idea though, I had to mull about it to find the flaw. :) Paolo