From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyzPl-0002sM-BM for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:11:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyzPi-0002w6-K9 for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:11:13 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:55962 helo=mx01.kamp.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1UyzPi-0002vp-9R for qemu-devel@nongnu.org; Tue, 16 Jul 2013 03:11:10 -0400 Message-ID: <51E4F200.1090808@kamp.de> Date: Tue, 16 Jul 2013 09:10:56 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1373885705-13722-1-git-send-email-pl@kamp.de> <51E46925.8040204@redhat.com> In-Reply-To: <51E46925.8040204@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv3] block-migration: efficiently encode zero blocks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, stefanha@redhat.com, pbonzini@redhat.com On 15.07.2013 23:27, Eric Blake wrote: > On 07/15/2013 04:55 AM, Peter Lieven wrote: >> this patch adds an efficient encoding for zero blocks by >> adding a new flag indiciating a block is completly zero. > s/indiciating/indicating/ > s/completly/completely/ > >> additionally bdrv_write_zeros() is used at the destination >> to efficiently write these zeroes. >> >> v2->v3: > patch revision history belongs outside of the commit message proper... > >> - changed type of flags in blk_send() from int to uint64_t >> - added migration capability setting to enable sending >> of zero blocks. >> >> Signed-off-by: Peter Lieven >> --- > ...here, after the --- separator. > >> block-migration.c | 29 +++++++++++++++++++++++------ >> include/migration/migration.h | 1 + >> migration.c | 9 +++++++++ >> qapi-schema.json | 7 ++++++- >> 4 files changed, 39 insertions(+), 7 deletions(-) >> +++ b/qapi-schema.json >> @@ -613,10 +613,15 @@ >> # Disabled by default. Experimental: may (or may not) be renamed after >> # further testing is complete. (since 1.6) >> # >> +# @zero-blocks: During storage migration encode blocks of zeroes efficiently. This >> +# essentially saves 1MB of zeroes per block on the wire. Enabling requires >> +# source and target VM to support this feature. Disabled by default. (since 1.6) > Does this capability have to be explicitly set on the receiving end, or > can it be automatic? I'd prefer automatic - where only the sending end > has to explicitly turn on the optimization. Only on the sending end. But you have to check that the receiver supports it as you figured out. I can update the comments if you like. > > Are there any downsides to unconditionally using this when it is > supported on both sides? With xbzrle, there are workloads where Downsides, not that I know of. The problem with xbzrle is that is is very complex and memory and network speed my be so high that not using XBZRLE can be better than enabling it. Here the only penalty is the zero blocks check which is lightning fast compared to disk access and the data is in memory anyway. The benefit is that you gain a lot. a) you save network bandwidth (which might be low). b) you can explicitly write zeroes at the end. with the write zero optimizations that exist for various drivers this can be a huge benefit in the form that it keeps the target thin-provisioned. Otherwise a block migration would always mean the target is fully allocated. Peter