From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUhih-0002xt-99 for qemu-devel@nongnu.org; Wed, 16 May 2012 13:09:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUhic-0006Rk-4O for qemu-devel@nongnu.org; Wed, 16 May 2012 13:09:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUhib-0006RT-TQ for qemu-devel@nongnu.org; Wed, 16 May 2012 13:08:58 -0400 Message-ID: <4FB3D5B9.8000604@redhat.com> Date: Wed, 16 May 2012 10:28:41 -0600 From: Eric Blake MIME-Version: 1.0 References: <1337169582-28312-1-git-send-email-owasserm@redhat.com> <1337169582-28312-4-git-send-email-owasserm@redhat.com> In-Reply-To: <1337169582-28312-4-git-send-email-owasserm@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig6C82C614767FB34DE0961FDF" Subject: Re: [Qemu-devel] [PATCH v10 3/9] Add XBZRLE documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Orit Wasserman Cc: aliguori@us.ibm.com, quintela@redhat.com, stefanha@gmail.com, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, avi@redhat.com, pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6C82C614767FB34DE0961FDF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/16/2012 05:59 AM, Orit Wasserman wrote: > Signed-off-by: Orit Wasserman > --- > docs/xbzrle.txt | 97 +++++++++++++++++++++++++++++++++++++++++++++++= ++++++++ > 1 files changed, 97 insertions(+), 0 deletions(-) > create mode 100644 docs/xbzrle.txt >=20 > diff --git a/docs/xbzrle.txt b/docs/xbzrle.txt > new file mode 100644 > index 0000000..aafdb84 > --- /dev/null > +++ b/docs/xbzrle.txt > @@ -0,0 +1,97 @@ > +XBZRLE (Xor Based Zero Run Length Encoding) > +=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 > + > +Using XBZRLE (Xor Based Zero Run Length Encoding) allows for the reduc= tion of VM downtime > +and the total live-migration time of Virtual machines. It is particula= rly useful for virtual machines running memory write intensive workloads = that are typical of large enterprise applications such as SAP ERP Systems= , and generally Any reason you aren't wrapping at column 80? > +speaking for any application that uses a sparse memory update pattern.= > + > +Instead of sending the changed guest memory page this solution will se= nd a compressed version of the updates, thus reducing the amount of data = sent during live migration. > +In order to be able to calculate the update, the previous memory pages= needed to be stored. Those pages are stored in a dedicated cache (hash t= able) and are accessed by their address. > +The larger the cache size the better the chances are that the page has= already been stored in the cache. A Small cache size will result in high= cache miss rate. s/Small/small/ > +Usage > +=3D=3D=3D=3D=3D=3D > + > +1. Activate xbzrle > +2. Set the XBZRLE cache size - the cache size is in MBytes and should = be a power of 2. The cache default value is 64MBytes. > +3. start outgoing migration > + > +A typical usage scenario: > + {qemu} migrate_set_parameter xbzrle > + {qemu} migrate_set_cachesize 256m > + {qemu} migrate -d tcp:destination.host:4444 > + {qemu} info migrate > + ... > + transferred ram-duplicate: A kbytes > + transferred ram-normal: B kbytes > + transferred ram-xbrle: C kbytes > + overflow ram-xbrle: D pages > + cache-miss ram-xbrle: E pages > + > +cache-miss: the number of cache misses to date - high cache-miss rate > +indicates that the cache size is set too low. > +overflow: the number of overflows in the decoding which where the delt= a could not be compressed. This can happen if the changes in the pages ar= e too large > +or there are many short changes for example change every second byte (= half a page). Can cachesize be modified during an in-progress migration? Do both source and destination need to agree on cache size? --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig6C82C614767FB34DE0961FDF 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.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPs9W5AAoJEKeha0olJ0Nq4ZEH/j90KlWBSlvnJAFBDWR6K0v7 iBSTrcEA9rdQSEaJS5lKUKipGrAlq7SbClxQ/w/oxS5iMxZCR/BR+i7hPFV28Uw+ qEQITyfcinpWc0z4ISRSrDFwCxrH1Xb0yeasPJihluNjG4XuuOAEdpIjyEmAxy3Z AX2zSB3CMamQcStUhAvnxhNEI9ZrpIQxbc4+QSN+nwy7Zx3y3gASYTzoeXLRnkPm oRieCOCJt8ZRk6joZJBqMZSxnDuBPiayzF1vkzdRfLkQCb+Ghhu7kfmlWGnrvUBm qjPKaWqIpJg0/k1TIfOljpK5Fpl2h8lT1CxjTe0UWslMxZXtdCNZHR48VXraXqE= =h0a1 -----END PGP SIGNATURE----- --------------enig6C82C614767FB34DE0961FDF--