From: Anthony Liguori <anthony@codemonkey.ws>
To: dlaor@redhat.com
Cc: Glauber Costa <glommer@redhat.com>, Uri Lublin <uril@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] ram_save_live: add a no-progress convergence rule
Date: Tue, 19 May 2009 13:15:32 -0500 [thread overview]
Message-ID: <4A12F744.3080809@codemonkey.ws> (raw)
In-Reply-To: <4A12C942.4090708@redhat.com>
Dor Laor wrote:
> The problem is that if migration is not progressing since the guest is
> dirtying pages
> faster than the migration protocol can send, than we just waist time
> and cpu.
> The minimum is to notify the monitor interface in order to let mgmt
> daemon to trap it.
> We can easily see this issue while running iperf in the guest or any
> other high load/dirty
> pages scenario.
The problem is, what's the metric for determining the guest isn't
progressing? A raw iteration count is not a valid metric. It may be
expected that the migration take 50 iterations.
The management tool knows the guest isn't progressing when it decides
that a guest isn't progressing :-)
> We can also make it configurable using the monitor migrate command.
> For example:
> migrate -d -no_progress -threshold=x tcp:....
Theshold is really a bad metric to use. You have no idea how much data
has been passed in each iteration. If you only needed one more
iteration, then stopping the migration short was a really bad idea.
The only thing that this does is give a false sense of security.
Management tools have to deal with forcing migration convergence based
on policies. If a management tool isn't doing this today, it's broken IMHO.
Basically, threshold introduces a regression. If you run iperf and
migrate a guest with a very large memory size, after migration, you'll
get soft lockups because the guest hasn't been running for 10 seconds.
This is bad.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2009-05-19 18:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-19 11:09 [Qemu-devel] [PATCH] ram_save_live: add a no-progress convergence rule Uri Lublin
2009-05-19 13:00 ` Anthony Liguori
2009-05-19 14:41 ` Glauber Costa
2009-05-19 14:59 ` Dor Laor
2009-05-19 15:09 ` Glauber Costa
2009-05-19 18:17 ` Anthony Liguori
2009-05-20 16:56 ` Uri Lublin
2009-05-20 17:28 ` Blue Swirl
2009-05-20 17:34 ` Uri Lublin
2009-05-19 18:19 ` Anthony Liguori
2009-05-19 18:15 ` Anthony Liguori [this message]
2009-05-20 17:17 ` Uri Lublin
2009-05-19 18:09 ` Anthony Liguori
2009-05-20 17:25 ` Uri Lublin
2009-05-20 17:15 ` Daniel P. Berrange
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=4A12F744.3080809@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=dlaor@redhat.com \
--cc=glommer@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=uril@redhat.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).