From: Orit Wasserman <owasserm@redhat.com>
To: qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, aliguori@us.ibm.com,
quintela@redhat.com, stefanha@gmail.com,
mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com,
Orit Wasserman <owasserm@redhat.com>,
chegu_vinod@hp.com, avi@redhat.com, pbonzini@redhat.com,
eblake@redhat.com
Subject: [Qemu-devel] [PATCH v14 03/13] Add XBZRLE documentation
Date: Tue, 3 Jul 2012 16:52:44 +0300 [thread overview]
Message-ID: <1341323574-23206-4-git-send-email-owasserm@redhat.com> (raw)
In-Reply-To: <1341323574-23206-1-git-send-email-owasserm@redhat.com>
Signed-off-by: Orit Wasserman <owasserm@redhat.com>
---
docs/xbzrle.txt | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 133 insertions(+), 0 deletions(-)
create mode 100644 docs/xbzrle.txt
diff --git a/docs/xbzrle.txt b/docs/xbzrle.txt
new file mode 100644
index 0000000..f00d63f
--- /dev/null
+++ b/docs/xbzrle.txt
@@ -0,0 +1,133 @@
+XBZRLE (Xor Based Zero Run Length Encoding)
+===========================================
+
+Using XBZRLE (Xor Based Zero Run Length Encoding) allows for the reduction
+of VM downtime and the total live-migration time of Virtual machines.
+It is particularly useful for virtual machines running memory write intensive
+workloads that are typical of large enterprise applications such as SAP ERP
+Systems, and generally speaking for any application that uses a sparse memory
+update pattern.
+
+Instead of sending the changed guest memory page this solution will send 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 need to
+be stored on the source. Those pages are stored in a dedicated cache
+(hash table) 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.
+Cache size can be changed before and during migration.
+
+Format
+=======
+
+The compression format performs a XOR between the previous and current content
+of the page, where zero represents an unchanged value.
+The page data delta is represented by zero and non zero runs.
+A zero run is represented by its length (in bytes).
+A non zero run is represented by its length (in bytes) and the new data.
+The run length is encoded using ULEB128 (http://en.wikipedia.org/wiki/LEB128)
+
+There can be more than one valid encoding, the sender may send a longer encoding
+for the benefit of reducing computation cost.
+
+page = zrun nzrun
+ | zrun nzrun page
+
+zrun = length
+
+nzrun = length byte...
+
+length = uleb128 encoded integer
+
+On the sender side XBZRLE is used as a compact delta encoding of page updates,
+retrieving the old page content from the cache (default size of 512 MB). The
+receiving side uses the existing page's content and XBZRLE to decode the new
+page's content.
+
+This work was originally based on research results published
+VEE 2011: Evaluation of Delta Compression Techniques for Efficient Live
+Migration of Large Virtual Machines by Benoit, Svard, Tordsson and Elmroth.
+Additionally the delta encoder XBRLE was improved further using the XBZRLE
+instead.
+
+XBZRLE has a sustained bandwidth of 2-2.5 GB/s for typical workloads making it
+ideal for in-line, real-time encoding such as is needed for live-migration.
+
+Example
+old buffer:
+1000 zeros
+05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 00 00 6b 00 6d
+3072 zeros
+
+new buffer:
+1000 zeros
+01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 00 67 00 69
+3702 zeros
+
+encoded buffer:
+
+encoded length 29
+e8 07 18 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 00 67 00 69 00 00
+00 80 18
+
+Migration Capabilities
+======================
+In order to use XBZRLE the destination QEMU version should be able to
+decode the new format.
+Adding a new migration capabilities command that will allow external management
+to query for it support.
+A typical use for the destination
+ {qemu} info migrate_capabilities
+ {qemu} xbzrle, ...
+
+In order to enable capabilities for future live migration,
+a new command migrate_set_parameter is introduced:
+ {qemu} migrate_set_parameter xbzrle
+
+Usage
+======
+
+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 delta could
+not be compressed. This can happen if the changes in the pages are too large
+or there are many short changes; for example, changing every second byte (half a
+page).
+
+Testing: Testing indicated that live migration with XBZRLE was completed in 110
+seconds, whereas without it would not be able to complete.
+
+A simple synthetic memory r/w load generator:
+.. include <stdlib.h>
+.. include <stdio.h>
+.. int main()
+.. {
+.. char *buf = (char *) calloc(4096, 4096);
+.. while (1) {
+.. int i;
+.. for (i = 0; i < 4096 * 4; i++) {
+.. buf[i * 4096 / 4]++;
+.. }
+.. printf(".");
+.. }
+.. }
--
1.7.7.6
next prev parent reply other threads:[~2012-07-03 13:53 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 13:52 [Qemu-devel] [PATCH v14 00/13] XBZRLE delta for live migration of large memory app Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 01/13] Add MigrationParams structure Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 02/13] Add migration capabilities Orit Wasserman
2012-07-03 18:36 ` Eric Blake
2012-07-05 10:09 ` Orit Wasserman
2012-07-03 13:52 ` Orit Wasserman [this message]
2012-07-03 19:45 ` [Qemu-devel] [PATCH v14 03/13] Add XBZRLE documentation Eric Blake
2012-07-04 8:29 ` Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 04/13] Add cache handling functions Orit Wasserman
2012-07-03 19:23 ` Blue Swirl
2012-07-03 19:49 ` Eric Blake
2012-07-04 7:04 ` Orit Wasserman
2012-07-03 20:24 ` Eric Blake
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 05/13] Add uleb encoding/decoding functions Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 06/13] Add save_block_hdr function Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 07/13] Add debugging infrastructure Orit Wasserman
2012-07-03 19:25 ` Blue Swirl
2012-07-04 7:19 ` Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 08/13] Change ram_save_block to return -1 if there are no more changes Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 09/13] Add migration_end function Orit Wasserman
2012-07-03 20:38 ` Eric Blake
2012-07-04 7:19 ` Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 10/13] Add xbzrle_encode_buffer and xbzrle_decode_buffer functions Orit Wasserman
2012-07-03 21:32 ` Eric Blake
2012-07-03 21:39 ` Eric Blake
2012-07-04 0:20 ` Eric Blake
2012-07-04 12:51 ` Orit Wasserman
2012-07-04 7:24 ` Orit Wasserman
2012-07-04 11:36 ` Eric Blake
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 11/13] Add XBZRLE to ram_save_block and ram_save_live Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 12/13] Add set_cachesize command Orit Wasserman
2012-07-03 13:52 ` [Qemu-devel] [PATCH v14 13/13] Add XBZRLE statistics Orit Wasserman
2012-07-04 1:35 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1341323574-23206-4-git-send-email-owasserm@redhat.com \
--to=owasserm@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=chegu_vinod@hp.com \
--cc=eblake@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).