From: Juan Quintela <quintela@redhat.com>
To: Chegu Vinod <chegu_vinod@hp.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org,
anthony@codemonkey.ws, owasserm@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v2] Throttle-down guest when live migration does not converge.
Date: Tue, 30 Apr 2013 18:01:52 +0200 [thread overview]
Message-ID: <87y5c0knwv.fsf@elfo.elfo> (raw)
In-Reply-To: <517FE964.2050702@hp.com> (Chegu Vinod's message of "Tue, 30 Apr 2013 08:55:16 -0700")
Chegu Vinod <chegu_vinod@hp.com> wrote:
> On 4/30/2013 8:20 AM, Juan Quintela wrote:
>>>
>>> (qemu) info migrate
>>> capabilities: xbzrle: off auto-converge: off <----
>>> Migration status: active
>>> total time: 1487503 milliseconds
>> 148 seconds
>
> 1487 seconds and still the Migration is not completed.
>
>>
>>> expected downtime: 519 milliseconds
>>> transferred ram: 383749347 kbytes
>>> remaining ram: 2753372 kbytes
>>> total ram: 268444224 kbytes
>>> duplicate: 65461532 pages
>>> skipped: 64901568 pages
>>> normal: 95750218 pages
>>> normal bytes: 383000872 kbytes
>>> dirty pages rate: 67551 pages
>>>
>>> ---
>>>
>>> (qemu) info migrate
>>> capabilities: xbzrle: off auto-converge: on <----
>>> Migration status: completed
>>> total time: 241161 milliseconds
>>> downtime: 6373 milliseconds
>> 6.3 seconds and finished, not bad at all O:-)
> That's the *downtime*.. The total time for migration to complete is
> 241 secs. (SpecJBB is
> one of those workloads that dirties memory quite a bit).
Sorry, you are right. Imressive anyways for such small change.
>>> +/* To reduce the dirty rate explicitly disallow the VCPUs from spending
>>> + much time in the VM. The migration thread will try to catchup.
>>> + Workload will experience a greater performance drop but for a shorter
>>> + duration.
>>> +*/
>>> +void *migration_throttle_down(void *opaque)
>>> +{
>>> + throttling = true;
>>> + while (throttling_needed()) {
>>> + CPUArchState *penv = first_cpu;
>> I am not sure that we can follow the list without the iothread lock
>> here.
>
> Hmm.. Is this due to vcpu hot plug that might happen at the time of
> live migration (or) due
> to something else ? I was trying to avoid holding the iothread lock
> for longer duration and slow
> down the migration thread...
Well, thinking back about it, what we should do is disable cpu
hotplug/unplug during migration (it is not working well anyways as
Today).
Thanks, Juan.
next prev parent reply other threads:[~2013-04-30 16:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-27 20:50 [Qemu-devel] [RFC PATCH v2] Throttle-down guest when live migration does not converge Chegu Vinod
2013-04-29 14:53 ` Eric Blake
2013-04-29 17:48 ` Chegu Vinod
2013-04-30 15:04 ` Orit Wasserman
2013-04-30 17:51 ` Chegu Vinod
2013-04-30 15:20 ` Juan Quintela
2013-04-30 15:55 ` Chegu Vinod
2013-04-30 16:01 ` Juan Quintela [this message]
2013-04-30 17:48 ` Chegu Vinod
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=87y5c0knwv.fsf@elfo.elfo \
--to=quintela@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=chegu_vinod@hp.com \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.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 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.