From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Alex Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] migration: broken ram_save_pending
Date: Tue, 04 Feb 2014 11:46:59 +0100 [thread overview]
Message-ID: <52F0C523.30102@redhat.com> (raw)
In-Reply-To: <52F0938F.2040102@ozlabs.ru>
Il 04/02/2014 08:15, Alexey Kardashevskiy ha scritto:
> So. migration_thread() gets dirty pages number, tries to send them in a
> loop but every iteration resets the number of pages to 96 and we start
> again. After several tries we cross BUFFER_DELAY timeout and calculate new
> @max_size and if the host machine is fast enough it is bigger than 393216
> and next loop will finally finish the migration.
This should have happened pretty much immediately, because it's not
while (pending()) but rather
while (pending_size && pending_size >= max_size)
(it's an "if" in the code, but the idea is the same). And max_size is
the following:
max_size = bandwidth * migrate_max_downtime() / 1000000;
With the default throttling of 32 MiB/s, bandwidth must be something
like 33000 (expressed in bytes/ms) with the default settings, and then
max_size should be 33000*3*10^9 / 10^6 = 6000000. Where is my
computation wrong?
Also, did you profile it to find the hotspot? Perhaps the bitmap
operations are taking a lot of time. How big is the guest? Juan's
patches were optimizing the bitmaps but not all of them apply to your
case because of hpratio.
> I can only think of something simple like below and not sure it does not
> break other things. I would expect ram_save_pending() to return correct
> number of bytes QEMU is going to send rather than number of pages
> multiplied by 4096 but checking if all these pages are really empty is not
> too cheap.
If you use qemu_update_position you will use very little bandwidth in
the case where a lot of pages are zero.
What you mention in ram_save_pending() is not problematic just because
of finding if the pages are empty, but also because you have to find the
nonzero spots in the bitmap!
Paolo
> Thanks!
>
>
> diff --git a/arch_init.c b/arch_init.c
> index 2ba297e..90949b0 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -537,16 +537,17 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
> acct_info.dup_pages++;
> }
> }
> } else if (is_zero_range(p, TARGET_PAGE_SIZE)) {
> acct_info.dup_pages++;
> bytes_sent = save_block_hdr(f, block, offset, cont,
> RAM_SAVE_FLAG_COMPRESS);
> qemu_put_byte(f, 0);
> + qemu_update_position(f, TARGET_PAGE_SIZE);
> bytes_sent++;
> } else if (!ram_bulk_stage && migrate_use_xbzrle()) {
> current_addr = block->offset + offset;
> bytes_sent = save_xbzrle_page(f, p, current_addr, block,
> offset, cont, last_stage);
> if (!last_stage) {
> p = get_cached_data(XBZRLE.cache, current_addr);
> }
>
>
next prev parent reply other threads:[~2014-02-04 10:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 7:15 [Qemu-devel] migration: broken ram_save_pending Alexey Kardashevskiy
2014-02-04 10:46 ` Paolo Bonzini [this message]
2014-02-04 11:59 ` Alexey Kardashevskiy
2014-02-04 12:07 ` Paolo Bonzini
2014-02-04 12:16 ` Alexey Kardashevskiy
2014-02-04 14:00 ` Paolo Bonzini
2014-02-04 22:17 ` Alexey Kardashevskiy
2014-02-05 7:18 ` Paolo Bonzini
2014-02-05 9:09 ` Dr. David Alan Gilbert
2014-02-05 16:35 ` Paolo Bonzini
2014-02-05 16:42 ` Dr. David Alan Gilbert
2014-02-05 16:45 ` Paolo Bonzini
2014-02-06 3:10 ` Alexey Kardashevskiy
2014-02-06 11:24 ` Dr. David Alan Gilbert
2014-02-07 5:39 ` Alexey Kardashevskiy
2014-02-07 8:55 ` Dr. David Alan Gilbert
2014-02-06 23:49 ` Paolo Bonzini
2014-02-07 5:42 ` Alexey Kardashevskiy
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=52F0C523.30102@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--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).