From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xlgji-0004Yr-7s for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:13:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xlgje-00041K-24 for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:13:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xlgjd-00041G-Q7 for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:13:33 -0500 Message-ID: <5458FB29.3090804@redhat.com> Date: Tue, 04 Nov 2014 17:13:29 +0100 From: Eric Blake MIME-Version: 1.0 References: <1414734011-16001-1-git-send-email-liangx.z.li@intel.com> In-Reply-To: <1414734011-16001-1-git-send-email-liangx.z.li@intel.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FNP4Mc5glblbPRQAGmoUhXA9f3jhA5L49" Subject: Re: [Qemu-devel] [PATCH 1/2] migration: Implement a multiple compress threads feature to accelerate live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liliang , qemu-devel@nongnu.org Cc: Li Liang , armbru@redhat.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FNP4Mc5glblbPRQAGmoUhXA9f3jhA5L49 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/31/2014 06:40 AM, Liliang wrote: > From: Li Liang >=20 [metacomment] This message does not contain an 'In-Reply-To' header, and thus does not appear threaded in spite of the name indicating that it is part of a series. You generally want to make sure that all patches in a series are in reply to the 0/n cover letter. > Instead of sending the guest memory directly, this solution compress th= e > ram page before sending, after receiving, the data will be decompressed= =2E > This feature can help to reduce the data transferred about 60%, this > is very useful when the network bandwidth is limited, and the migration= > time can also be reduced about 80%. The feature is off by default, > fllowing the document docs/multiple-compression-threads.txt for s/fllowing/following/ Umm, that file doesn't exist in the tree yet. But I finally located your 2/2 patch that proposes to add it; I suggest you rebase the series to propose the docs first (for more rationale why, look at http://wiki.qemu.org/Contribute/SubmitAPatch) > information to use it. >=20 > Signed-off-by: Li Liang > --- > +++ b/qapi-schema.json > @@ -497,7 +497,7 @@ > # Since: 1.2 > ## > { 'enum': 'MigrationCapability', > - 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks'] }= > + 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks', '= compress'] } Missing documentation of the 'compress' flag, including the fact that it is '(since 2.3)'. > =20 > ## > # @MigrationCapabilityStatus > @@ -1382,6 +1382,88 @@ > { 'command': 'query-migrate-cache-size', 'returns': 'int' } > =20 > ## > +# @migrate-set-compress-level > +# > +# Set compress level > +# > +# @value: compress level int > +# > +# The compress level will be an integer between 0 and 9. > +# The compress level can be modified before and during ongoing migrati= on > +# > +# Returns: nothing on success > +# > +# Since: 1.2 Wrong. This was not part of qemu 1.2. The earliest it can be included is 2.3. Also, I'm not a fan of adding yet more one-off migration tunable commands. I have had threads in the mailing list archives before about a proposal to make migration tunables more generic (right now, MigrationCapability is a set of boolean-only fields, but I had a proposal that would make it a union type where we could then add integer capabilities, and then your compression level would set the actual integer capability rather than just being a boolean). Alas, I'm not in a good position to search the archives for my previous proposals at the moment, or I would point you to a URL of the archived message... > +## > +{ 'command': 'migrate-set-compress-level', 'data': {'value': 'int'} } > + > +## > +# @query-migrate-compress-level > +# > +# query compress level > +# > +# Returns: compress level int > +# > +# Since: 1.2 Again, should be 2.3, and may be overkill if we instead enhance the existing migration capabilities to express multiple types (my same proposal mentioned above). > +## > +{ 'command': 'query-migrate-compress-level', 'returns': 'int' } > + > +## > +# @migrate-set-compress-threads > +# > +# Set compress threads > +# > +# @value: compress threads int > +# > +# The compress thread count is an integer between 1 and 255. > +# The compress level can be modified only before migration > +# > +# Returns: nothing on success > +# > +# Since: 1.2 Same story. > +## > +{ 'command': 'migrate-set-compress-threads', 'data': {'value': 'int'} = } > + > +## > +# @query-migrate-compress-threads > +# > +# query compress threads > +# > +# Returns: compress threads int > +# > +# Since: 1.2 and again > +## > +{ 'command': 'query-migrate-compress-threads', 'returns': 'int' } > + > +## > +## > +# @migrate-set-decompress-threads > +# > +# Set decompress threads > +# > +# @value: decompress threads int > +# > +# The decompress thread count is an integer between 1 and 64. > +# The decompress level can be modified only before migration > +# > +# Returns: nothing on success > +# > +# Since: 1.2 and again. Why is this limited to 64 threads, when compression is allowed 255 threads? > +## > +{ 'command': 'migrate-set-decompress-threads', 'data': {'value': 'int'= } } > + > +## > +# @query-migrate-decompress-threads > +# > +# query decompress threads > +# > +# Returns: decompress threads int > +# > +# Since: 1.2 and again > +## > +{ 'command': 'query-migrate-decompress-threads', 'returns': 'int' } > + > +## > # @ObjectPropertyInfo: > # > # @name: the name of the property --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --FNP4Mc5glblbPRQAGmoUhXA9f3jhA5L49 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUWPspAAoJEKeha0olJ0NqejsH/22y47bs3i179DGDQo6xEybK a0dish4PlP17LdOn7HhWAEaMj2omuSnie1N8yuC1/iYW1DSj1gMQFatXg3pn5dB+ orL+quve1zF5LtvlUtJQbdfqo/2Zw/8V98ofo9oxhT6aQhlDJ7PrfkaoFeYibea5 eVL5T7bhja9aoBGz0CzvQ6JKz8DkSC594AyMDxbRMKNtYIafrqm+bxNAzRGy9vCj ZbjAr/0yFCyHk8JdI3kKbh9WV9pTVy0gjLK8zpMNNkDp1VutLEndRuzcaYLo+5p3 piJGt0T1//P2P+spS1b1SLzABkrpXl3kK/2BYshfhDd/j+N/zJdZuu5eOtZNepg= =SSrD -----END PGP SIGNATURE----- --FNP4Mc5glblbPRQAGmoUhXA9f3jhA5L49--