From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyqId-0005MB-Kv for qemu-devel@nongnu.org; Mon, 15 Jul 2013 17:27:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyqIZ-0005FJ-5N for qemu-devel@nongnu.org; Mon, 15 Jul 2013 17:27:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyqIY-0005F0-S5 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 17:27:11 -0400 Message-ID: <51E46925.8040204@redhat.com> Date: Mon, 15 Jul 2013 15:27:01 -0600 From: Eric Blake MIME-Version: 1.0 References: <1373885705-13722-1-git-send-email-pl@kamp.de> In-Reply-To: <1373885705-13722-1-git-send-email-pl@kamp.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2OLAMELHEPXNLBTUPRRXO" Subject: Re: [Qemu-devel] [PATCHv3] block-migration: efficiently encode zero blocks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kwolf@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, stefanha@redhat.com, pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OLAMELHEPXNLBTUPRRXO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/ >=20 > additionally bdrv_write_zeros() is used at the destination > to efficiently write these zeroes. >=20 > 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. >=20 > Signed-off-by: Peter Lieven > --- =2E..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(-) >=20 > +++ b/qapi-schema.json > @@ -613,10 +613,15 @@ > # Disabled by default. Experimental: may (or may not) be rena= med after > # further testing is complete. (since 1.6) > # > +# @zero-blocks: During storage migration encode blocks of zeroes effic= iently. This > +# essentially saves 1MB of zeroes per block on the wire. Enab= ling requires > +# source and target VM to support this feature. Disabled by d= efault. (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. Are there any downsides to unconditionally using this when it is supported on both sides? With xbzrle, there are workloads where enabling the feature can actually penalize performance, so libvirt exposed the choice of using the feature through its API to the end user. But if I understand this feature, there are no downsides to using it, other than generating a migration stream that the destination will not understand. Thus, I don't think libvirt public-facing APIs need to change, and that it is just a matter of implementing this in libvirt internals that coordinate the start of a migration: old -> old: feature not present on source, not enabled old -> new: feature not present on source, not enabled new -> old: feature present on source, so query destination; feature not present on destination, so not enabled new -> new: feature present on source, so query destination; feature present on destination, so use it At any rate, the interface looks sane; Reviewed-by: Eric Blake --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2OLAMELHEPXNLBTUPRRXO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJR5GklAAoJEKeha0olJ0NqrXoH/RUcL8S9DE24DMYVxIfmq6rV 52YoGbLy44bboSaeKQ5mXH0GxrCJJtIvsdOWVW8Ug5xxVQwaV8G031JQUJOFic6s PbEq4DlOLVAEs4hm2L4sNkcIlJP3LipFPhxtXNQkYIMw1bA20Aki7P+eIOimOhmK qa4NhSOHAEKlz1mi8NU+nvMIUgZrmmWBBOc6zRPF+lFsy66v0z8zUKLJsiWUX91h nmIHwlIrOA54f7HnSz8n3GizN4hA9WW4A+PQej6D8sSDECSGTCC6ejyFuejD75dA N7WOXNftzYl9Q7fFuoAJJ7GO27IDCDMFteJI+kYbX3rZDmbfQxxX3ZYA9PdMgZU= =LKKO -----END PGP SIGNATURE----- ------enig2OLAMELHEPXNLBTUPRRXO--