qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: quintela@redhat.com, Chegu Vinod <chegu_vinod@hp.com>,
	qemu-devel@nongnu.org, owasserm@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v5 3/3] Force auto-convegence of live migration
Date: Fri, 10 May 2013 10:08:05 -0500	[thread overview]
Message-ID: <87li7mzxd6.fsf@codemonkey.ws> (raw)
In-Reply-To: <20130510141759.GO13475@redhat.com>

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Fri, May 10, 2013 at 08:07:51AM -0500, Anthony Liguori wrote:
>> Chegu Vinod <chegu_vinod@hp.com> writes:
>> 
>> >  If a user chooses to turn on the auto-converge migration capability
>> >  these changes detect the lack of convergence and throttle down the
>> >  guest. i.e. force the VCPUs out of the guest for some duration
>> >  and let the migration thread catchup and help converge.
>> >
>> >  Verified the convergence using the following :
>> >  - SpecJbb2005 workload running on a 20VCPU/256G guest(~80% busy)
>> >  - OLTP like workload running on a 80VCPU/512G guest (~80% busy)
>> >
>> >  Sample results with SpecJbb2005 workload : (migrate speed set to 20Gb and
>> >  migrate downtime set to 4seconds).
>> 
>> Would it make sense to separate out the "slow the VCPU down" part of
>> this?
>> 
>> That would give a management tool more flexibility to create policies
>> around slowing the VCPU down to encourage migration.
>> 
>> In fact, I wonder if we need anything in the migration path if we just
>> expose the "slow the VCPU down" bit as a feature.
>> 
>> Slow the VCPU down is not quite the same as setting priority of the VCPU
>> thread largely because of the QBL so I recognize the need to have
>> something for this in QEMU.
>
> Rather than the priority, could you perhaps do the VCPU slow down
> using  cfs_quota_us + cfs_period_us settings though ? These let you
> place hard caps on schedular time afforded to vCPUs and we can already
> control those via libvirt + cgroups.

The problem with the bandwidth controller is the same with priorities.
You can end up causing lock holder pre-emption which would negatively
impact migration performance.

It's far better for QEMU to voluntarily give up some time knowing that
it's not holding the QBL since then migration can continue without
impact.

Regards,

Anthony Liguori

>
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

  reply	other threads:[~2013-05-10 15:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-09 19:43 [Qemu-devel] [RFC PATCH v5 0/3] Throttle-down guest to help with live migration convergence Chegu Vinod
2013-05-09 19:43 ` [Qemu-devel] [RFC PATCH v5 1/3] Introduce async_run_on_cpu() Chegu Vinod
2013-05-10  7:43   ` Paolo Bonzini
2013-05-09 19:43 ` [Qemu-devel] [RFC PATCH v5 2/3] Add 'auto-converge' migration capability Chegu Vinod
2013-05-10  7:43   ` Paolo Bonzini
2013-05-10 14:26     ` Eric Blake
2013-05-09 19:43 ` [Qemu-devel] [RFC PATCH v5 3/3] Force auto-convegence of live migration Chegu Vinod
2013-05-09 20:05   ` Igor Mammedov
2013-05-09 22:26     ` Chegu Vinod
2013-05-09 20:24   ` Igor Mammedov
2013-05-09 23:00     ` Chegu Vinod
2013-05-10  7:47       ` Paolo Bonzini
2013-05-10  7:41   ` Paolo Bonzini
2013-05-10 13:07   ` Anthony Liguori
2013-05-10 14:14     ` Chegu Vinod
2013-05-10 15:11       ` Anthony Liguori
2013-05-12 17:19         ` Paolo Bonzini
2013-05-13 12:18           ` Anthony Liguori
2013-05-10 14:17     ` Daniel P. Berrange
2013-05-10 15:08       ` Anthony Liguori [this message]
2013-05-13 12:33         ` 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=87li7mzxd6.fsf@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=berrange@redhat.com \
    --cc=chegu_vinod@hp.com \
    --cc=owasserm@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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).