qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dor Laor <dlaor@redhat.com>
To: Glauber Costa <glommer@redhat.com>
Cc: 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 17:59:14 +0300	[thread overview]
Message-ID: <4A12C942.4090708@redhat.com> (raw)
In-Reply-To: <20090519144101.GA16372@shell.devel.redhat.com>

Glauber Costa wrote:
> On Tue, May 19, 2009 at 08:00:48AM -0500, Anthony Liguori wrote:
>   
>> Uri Lublin wrote:
>>     
>>> Currently the live-part (section QEMU_VM_SECTION_PART) of
>>> ram_save_live has only one convergence rule, which is
>>> when the number of dirty pages is smaller than a threshold.
>>>
>>> When the guest uses more memory pages than the threshold (e.g.
>>> playing a movie, copying files, sending/receiving many packets),
>>> it may take a very long time before convergence according to
>>> this rule.
>>>
>>> This patch (re)introduces a no-progress convergence rule, which limit
>>> the number of times the migration process is not progressing
>>> (and even regressing), with regards to the number of dirty
>>> pages. No-progress means that the number of pages that got
>>> dirty is larger than the number of pages that got transferred
>>> to the destination during the last transfer.
>>> This rule applies only after the first round (in which most
>>> memory pages are being transferred).
>>>
>>> Also this patch enlarges the number-dirty-pages threshold (of
>>> the first convergence rule) to 50 pages (was 10)
>>>
>>> Signed-off-by: Uri Lublin <uril@redhat.com>
>>>  
>>>       
>> The right place to do this is in a management tool.  An arbitrary 
>> convergence rule of 50 can do more damage than good.
>>
>> For some set of users, it's better that live migration fail than it 
>> cause an arbitrarily long pause in the guest which can result in dropped 
>> TCP connections, soft lock ups, and other badness.
>>
>> A management tool can force convergence by issuing a "stop" command in 
>> the monitor.  I suspect a management tool cares more about wall-clock 
>> time than number of iterations too so a valid metric would be something 
>> along the lines of if not converged after N seconds, issue stop monitor 
>> command where N is calculated from available network bandwidth and guest 
>> memory size.
>>     
> Another possibility is for the management tool to increase the bandwidth for
> little periods if it perceives that no progress is being made.
>
> Anyhow, I completely agree that we should not introduce this in qemu.
>
> However, maybe we could augment our "info migrate" to provide more info about
> the internal state of migration, so the mgmt tool can take a more informed
> decision?
>
>   
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.

We can also make it configurable using the monitor migrate command. For 
example:
migrate -d -no_progress -threshold=x tcp:....

  reply	other threads:[~2009-05-19 14:58 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 [this message]
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
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=4A12C942.4090708@redhat.com \
    --to=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).