From: Stefan Hajnoczi <stefanha@gmail.com>
To: "Shribman, Aidan" <aidan.shribman@sap.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v3] XBZRLE delta for live migration of large memory apps
Date: Tue, 2 Aug 2011 19:05:54 +0100 [thread overview]
Message-ID: <20110802180554.GA13769@stefanha-thinkpad.localdomain> (raw)
In-Reply-To: <AB5A8C7661872E428D6B8E1C2DFA35085D848B5983@DEWDFECCR02.wdf.sap.corp>
On Tue, Aug 02, 2011 at 03:45:56PM +0200, Shribman, Aidan wrote:
> Subject: [PATCH v3] XBZRLE delta for live migration of large memory apps
> From: Aidan Shribman <aidan.shribman@sap.com>
>
> By using XBZRLE (Xor Binary Zero Run-Length-Encoding) we can reduce VM downtime
> and total live-migration time for VMs running memory write intensive workloads
> typical of large enterprise applications such as SAP ERP Systems, and generally
> speaking for representative of any application with a sparse memory update pattern.
>
> On the sender side XBZRLE is used as a compact delta encoding of page updates,
> retrieving the old page content from an LRU cache (default size of 64 MB). The
> receiving side uses the existing page content and XBZRLE to decode the new page
> content.
>
> 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 XBZRLE instead.
>
> XBZRLE has a sustained bandwidth of 1.5-2.2 GB/s for typical workloads making it
> ideal for in-line, real-time encoding such as is needed for live-migration.
What is the CPU cost of xbzrle live migration on the source host? I'm
thinking about a graph showing CPU utilization (e.g. from mpstat(1))
that has two datasets: migration without xbzrle and migration with
xbzrle.
> @@ -128,28 +288,35 @@ static int ram_save_block(QEMUFile *f)
> current_addr + TARGET_PAGE_SIZE,
> MIGRATION_DIRTY_FLAG);
>
> - p = block->host + offset;
> + if (arch_mig_state.use_xbrle) {
> + p = qemu_mallocz(TARGET_PAGE_SIZE);
qemu_malloc()
> +static uint8_t count_hash_bits(uint64_t v)
> +{
> + uint8_t bits = 0;
> +
> + while (!(v & 1)) {
> + v = v >> 1;
> + bits++;
> + }
> + return bits;
> +}
See ffs(3). ffsll() does what you need.
> +static uint8_t xor_buf[TARGET_PAGE_SIZE];
> +static uint8_t xbzrle_buf[TARGET_PAGE_SIZE * 2];
Do these need to be static globals? It should be fine to define them as
local variables inside the functions that need them, there is enough
stack space.
> +
> +int xbzrle_encode(uint8_t *xbzrle, const uint8_t *old, const uint8_t *curr,
> + const size_t max_compressed_len)
> +{
> + int compressed_len;
> +
> + xor_encode_word(xor_buf, old, curr);
> + compressed_len = rle_encode((uint64_t *)xor_buf,
> + sizeof(xor_buf)/sizeof(uint64_t), xbzrle_buf,
> + sizeof(xbzrle_buf));
> + if (compressed_len > max_compressed_len) {
> + return -1;
> + }
> + memcpy(xbzrle, xbzrle_buf, compressed_len);
Why the intermediate xbrzle_buf buffer and why the memcpy()?
return rle_encode((uint64_t *)xor_buf, sizeof(xor_buf) / sizeof(uint64_t),
xbzrle, max_compressed_len);
Stefan
next prev parent reply other threads:[~2011-08-02 18:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 13:45 [Qemu-devel] [PATCH v3] XBZRLE delta for live migration of large memory apps Shribman, Aidan
2011-08-02 14:01 ` Alexander Graf
2011-08-02 14:34 ` Paolo Bonzini
2011-08-02 15:00 ` Anthony Liguori
2011-08-04 9:31 ` Shribman, Aidan
2011-08-02 18:08 ` Stefan Hajnoczi
2011-08-02 22:38 ` Avi Kivity
2011-08-02 18:05 ` Stefan Hajnoczi [this message]
2011-08-08 8:42 ` Shribman, Aidan
2011-08-08 14:02 ` Stefan Hajnoczi
2011-08-02 20:43 ` Blue Swirl
2011-08-08 8:42 ` Shribman, Aidan
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=20110802180554.GA13769@stefanha-thinkpad.localdomain \
--to=stefanha@gmail.com \
--cc=aidan.shribman@sap.com \
--cc=qemu-devel@nongnu.org \
/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).