From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIpjQ-0003WY-9u for qemu-devel@nongnu.org; Tue, 03 Feb 2015 21:30:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIpjN-0001z1-4y for qemu-devel@nongnu.org; Tue, 03 Feb 2015 21:30:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIpgf-0000p1-18 for qemu-devel@nongnu.org; Tue, 03 Feb 2015 21:27:29 -0500 Message-ID: <54D1838B.9060103@redhat.com> Date: Tue, 03 Feb 2015 19:27:23 -0700 From: Eric Blake MIME-Version: 1.0 References: <1422875149-13198-1-git-send-email-liang.z.li@intel.com> <1422875149-13198-13-git-send-email-liang.z.li@intel.com> <54D159BB.2020205@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EMmOU6aLlbbmFjuCvlTrOI215HxuFSGJ4" Subject: Re: [Qemu-devel] [v4 12/13] migration: Add command to set migration parameter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Li, Liang Z" , "qemu-devel@nongnu.org" Cc: "quintela@redhat.com" , "armbru@redhat.com" , "dgilbert@redhat.com" , "Zhang, Yang Z" , "amit.shah@redhat.com" , "lcapitulino@redhat.com" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EMmOU6aLlbbmFjuCvlTrOI215HxuFSGJ4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/03/2015 06:26 PM, Li, Liang Z wrote: >> Hmm - do we really need two parameters here? Remember, compress >> threads is used only on the source, and decompress threads is used onl= y on >> the destination. Having a single parameter, 'threads', which is set t= o >> compression threads on source and decompression threads on destination= , >> and which need not be equal between the two machines, should still wor= k, >> right? >> >=20 > Yes, it works. The benefit of using one parameter instead of two can re= duce the QMP=20 > command count, and the side effect of using the same thread count for c= ompression > and decompression is a little waste if the user just want to use the d= efault settings, > you know, decompression is usually about 4 times faster than compressi= on. Use more > decompression threads than needed will waste some RAM which used to sav= e data=20 > structure related to the decompression thread, about 4K bytes RAM per t= hread, is it=20 > acceptable? The default setting is no compression. The user already has to configure things on both sides to get compression, so it is not a burden to ask them to configure thread count on both sides correctly. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --EMmOU6aLlbbmFjuCvlTrOI215HxuFSGJ4 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJU0YOLAAoJEKeha0olJ0Nq2jAH/ApiSPpspS/Hq7gHkOISuAe/ 3dlV97RKAqL6kPIHtDsdlHlTtkykWcp/ZkRWfog1daSpEVcmWX2f2gu8B1d14+r/ sCAaHz3TSLwKMmJ+ldD7ceewguGgCNnXxuzo6nh8C/x3nLnThkCqT2lsJ5yY+Gl7 I33rJ8z017HoWr7N/oUvEh6LKvRklzlLH8BdbIUGmEd33dkNLGlGT7yjHwwAfoqA VPEN7ltu+9hs29L3WQa3dmPgiLUg1d23bEXupxxZXDie+FdPqjti7xVA+VxEARQ7 SBM1sjGsSr5wEttawub31XZGXD2lLXYfTh5Cr4yMXjT2rUSdsN232s1vUs2vgxw= =cZLr -----END PGP SIGNATURE----- --EMmOU6aLlbbmFjuCvlTrOI215HxuFSGJ4--