Re: [Qemu-devel] [RFC PATCH v5 3/3] Force auto-convegence of live migration

["Daniel P. Berrange" <berrange@redhat.com>]

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.

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 :|