On Fri, May 10, 2013 at 08:07:51AM -0500, Anthony Liguori wrote: > Chegu Vinod <chegu_vi...@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 :|