From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlgnM-0007ok-4f for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:17:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlgnF-0005Xu-C4 for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:17:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlgnE-0005Xg-Vi for qemu-devel@nongnu.org; Tue, 04 Nov 2014 11:17:17 -0500 Message-ID: <5458FC08.1010702@redhat.com> Date: Tue, 04 Nov 2014 17:17:12 +0100 From: Eric Blake MIME-Version: 1.0 References: <1414734028-16045-1-git-send-email-liangx.z.li@intel.com> In-Reply-To: <1414734028-16045-1-git-send-email-liangx.z.li@intel.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="otFWvlCLFd57cho705T2jIC9pDgBc7E9I" Subject: Re: [Qemu-devel] [PATCH 2/2] docs: Add a document about multiple compression threads 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) --otFWvlCLFd57cho705T2jIC9pDgBc7E9I 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 > Give some details about how to use the multiple compress threads featur= e > in live migration. >=20 > Signed-off-by: Li Liang > --- > docs/multiple-compression-threads.txt | 57 +++++++++++++++++++++++++++= ++++++++ > 1 file changed, 57 insertions(+) > create mode 100644 docs/multiple-compression-threads.txt >=20 > diff --git a/docs/multiple-compression-threads.txt b/docs/multiple-comp= ression-threads.txt > new file mode 100644 > index 0000000..83e9e5b > --- /dev/null > +++ b/docs/multiple-compression-threads.txt > @@ -0,0 +1,57 @@ > +Use multiple compression(decompression) threads in live migration Missing a copyright notice (yeah, not all files in our docs directory are good examples, but we're starting to get better at it). > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +Instead of sending the guest memory directly, this solution will > +compress the ram page before sending, after receiving, the data how to= > +us will be decompressed. Using compression in live migration can help s/how to us will be/has to be/ ? > +to reduce the data transferred about 60%, this is very useful when the= > +bandwidth is limited, and the migration time can also be reduced about= > +80% in a typical case. What network bandwidth did you have in your tests? I suspect that the speedups you saw may be more pronounced on low-bandwidth links, and that you would be wise to give more details about reproducing your test setup, since not everyone will see the same speedups. > + > +The process of compression will consume additional CPU cycles, and the= > +extra CPU cycles will increase the migration time. In another hand, s/In another/On the other/ > +the amount of data transferred will reduced, this factor can reduce > +the migration time. If the process of the compression is quickly s/quickly/quick/ > +enough, then the total migration time can be reduced, multiple s/multiple/and multiple/ > +compression threads can be used to accelerate the compression process.= > + > +Compression level can be used to control the compression speed and the= > +compression ratio. High compression ratio will take more time, level 0= > +stands for no compression, level 1 stands for the best compression > +speed,and level 9 stands for the best compression ratio. Users can > +select a level number between 0 and 9. > + > + > +When to use the multiple compression threads in live migration > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +Compression of data will consume lot of extra CPU cycles, in a system > +with high overhead of CPU, avoid using this feature. When the network > +bandwidth is very limited and the CPU resource is adequate, use the > +multiple compression threads will be very helpful. If both the CPU and= > +the network bandwidth are adequate, use multiple compression threads > +can still help to reduce the migration time. > + > + > +Usage > +=3D=3D=3D=3D=3D=3D > +1. Verify the destination QEMU version is able to support the multiple= > +compression threads migration: > + {qemu} info_migrate_capablilites > + {qemu} ... compress: off ... > + > +2. Activate compression on the souce: > + {qemu} migrate_set_capability compress on > + > +3. Set the compression thread count on source: > + {qemu} migrate_set_compress_threads 10 > + > +4. Set the compression level on the source: > + {qemu} migrate_set_compress_level 1 > + > +5. Set the decompression thread count on destination: > + {qemu} migrate_set_decompress_threads 5 > + > +6. Start outgoing migration: > + {qemu} migrate -d tcp:destination.host:4444 > + {qemu} info migrate > + Capablilties: ... compress: on s/Capablilties/Capabilities/ --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --otFWvlCLFd57cho705T2jIC9pDgBc7E9I 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 iQEcBAEBCAAGBQJUWPwIAAoJEKeha0olJ0Nqa1wH/3LOSIQ9XmIK8EfOYBYC5NkD ZxNvDXowMxCNsKT9p/pyvtlPDVxVPEaaCqVouLLigGuWsBk3vQ5fWf8Qjhgnbnyc fLz7gTa0kejZXa19U+vh0FiUPgZGJF8r66q5iL8qRClAdbdsJtNavYYCCYAEl86N cWiurB/qadS4FNcWkg+dr5dRt5kRIKZCg2ixUIRVy+LxqBHBJg6oGxARi3YvA1bA ZwC+zQilea0pN9o50W0qk+Xc3hqtNAvrNt7poDQB9ax7HXXJncQRaVFPKgeTIhc6 PSVvzUsywRzT8AkwBMrbU9Va2nnV8QNc03LhUqSXXtnfj5ANkX8Dt5oA0ToWVHI= =RXpP -----END PGP SIGNATURE----- --otFWvlCLFd57cho705T2jIC9pDgBc7E9I--