From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmNOQ-0007QB-NF for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:46:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmNOM-0001fw-7x for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:46:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmNOM-0001fk-0C for qemu-devel@nongnu.org; Thu, 06 Nov 2014 08:46:26 -0500 Message-ID: <545B7BAC.40904@redhat.com> Date: Thu, 06 Nov 2014 14:46:20 +0100 From: Eric Blake MIME-Version: 1.0 References: <1415272128-8273-1-git-send-email-liang.z.li@intel.com> <1415272128-8273-2-git-send-email-liang.z.li@intel.com> <20141106132451.GA20765@work-vm> In-Reply-To: <20141106132451.GA20765@work-vm> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oU0etJt1P2tnaiO0NKSrtAsHRH1lHDoMN" Subject: Re: [Qemu-devel] [v2 1/2] docs: Add a doc about multiple compression threads List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , Li Liang Cc: quintela@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, yang.z.zhang@intel.com, amit.shah@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oU0etJt1P2tnaiO0NKSrtAsHRH1lHDoMN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/06/2014 02:24 PM, Dr. David Alan Gilbert wrote: > * Li Liang (liang.z.li@intel.com) wrote: >> Give some details about the multiple compression threads and how >> to use it in live migration. >> >> Signed-off-by: Li Liang >> --- >> +TODO >> +=3D=3D=3D=3D >> +Some faster compression/decompression method such as lz4 and quicklz >> +can help to reduce the CPU consumption when doing (de)compression. >> +Less (de)compression threads are needed when doing the migration. >=20 > OK, some high level questions: > 1) How does the performance compare to running a separate compressor= > process in the stream rather than embedding it in the qemu? Interesting question. I wonder if libvirt should be extended to optionally insert a compression/decompression filter in the setups it creates. Remember, in libvirt tunnelled mode, where libvirt is adding TLS encryption on top of the migration data stream so that it is not sniffable from TCP, all data is already going through the path: source qemu -> source libvirt -> destination libvirt -> destination qemu Unix socket/pipe TCP socket Unix socket/pipe Furthermore, libvirt is ALREADY wired up to use external compression when doing migration to file (such as supporting multiple compression formats for 'virsh save'), which looks like: qemu -> compressor -> libvirt I/O helper -> file pipe pipe O_DIRECT file ops then restoring that image with: file -> libvirt I/O helper -> decompressor -> qemu O_DIRECT file ops pipe pipe So adding compression in the mix seems like it would be easy for libvirt to do: source qemu -> compressor -> source libvirt -> destination libvirt ... pipe pipe TCP socket -> decompressor -> destination qemu pipe pipe Of course, with an external processor, I don't know if you can get speedups from having multiple compression threads when all input is coming serially from a single connection, so your approach of folding in parallel compression threads directly into qemu may still have some speed merits. On the other hand, I'm not sure how your solution is multiplexing the multiple compression threads into a single migration stream; if you are still bottlenecked by a single migration stream, what good do you get by adding multiple (de)compression threads, without some way in the migration protocol to cleanly call out a fair rotation from the independent sub-stream of each thread? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --oU0etJt1P2tnaiO0NKSrtAsHRH1lHDoMN 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 iQEcBAEBCAAGBQJUW3usAAoJEKeha0olJ0NqJkQH/28tzW54AMSKc0dd/uCMOa5s JVxhr9os6uj7/7Nn0jFlUNzEIQgxWQnXE3oGULqckhjicvw0kprlflPjFIXuyCnr Hepvx6YJX48UYqoQ3gJNH5eneqN659/vYALBwt7ysBdz+2gGLeC4buV0vCO27nR6 I7AT+MfHrSOcBuU1/CCYKuIwHxS6ujqfs9ENuaoctI5ap39mj1FFqVEGotJxiVyN vWhlYxM/812mC3LJ6TArm6/U/1/MU4TOa/D4fQ7DHEJhoHZHuj6GFEgBs++dNsVd XoTtb0g3iOfLzW4QbpRjFWHkd72p0kpeLeoVU/zssvJwzp07QKdrxRMSIz4sGM8= =vnDN -----END PGP SIGNATURE----- --oU0etJt1P2tnaiO0NKSrtAsHRH1lHDoMN--