All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Thomas Treutner <thomas@scripty.at>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Migration speed throttling, max_throttle in migration.c
Date: Wed, 09 Feb 2011 21:02:38 +0100	[thread overview]
Message-ID: <4D52F2DE.8070103@codemonkey.ws> (raw)
In-Reply-To: <4D52D95D.3030300@scripty.at>

On 02/09/2011 07:13 PM, Thomas Treutner wrote:
> Hi,
>
> I was reading qemu's (qemu-kvm-0.13.0's, to be specific) live 
> migration code to unterstand how the iterative dirty page transfer is 
> implemented. During this I noticed that ram_save_live in arch_init.c 
> is called quite often, more often than I expected (approx. 200 times 
> for an idle 500MiB VM). I found out that this is because of while 
> (!qemu_file_rate_limit(f)), which evaluates very often to true, and as 
> there are remaining dirty pages, ram_save_live is called again.
>
> As I had set no bandwith limit in the libvirt call, I digged deeper 
> and found a hard coded maximum bandwidth in migration.c:
>
> /* Migration speed throttling */
> static uint32_t max_throttle = (32 << 20);
>
> Using a packet sniffer I verified that max_throttle is Byte/s, here of 
> course 32 MiB/s. Additionally, it translates directly to network 
> bandwidth - I was not sure about that, as the bandwidth measured in 
> ram_save_live seems to be buffer/memory subsystem bandwidth?

Because that was roughly how fast my laptop's hard drive was and we had 
a very bad implementation of migration to file and the limit was the 
only way to avoid pausing the guest.

The reason it's still this today is mainly historic.  I've thought about 
making the default limit unlimited.  I'm not sure if anyone has strong 
opinions.

Regards,

Anthony Liguori

  reply	other threads:[~2011-02-09 20:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-09 18:13 [Qemu-devel] Migration speed throttling, max_throttle in migration.c Thomas Treutner
2011-02-09 20:02 ` Anthony Liguori [this message]
2011-02-09 21:18   ` Thomas Treutner
2011-02-10  5:52     ` Yoshiaki Tamura

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=4D52F2DE.8070103@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    --cc=thomas@scripty.at \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.