From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaoAz-0003GG-C6 for qemu-devel@nongnu.org; Fri, 10 May 2013 10:20:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaoAw-0001PQ-SM for qemu-devel@nongnu.org; Fri, 10 May 2013 10:20:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaoAw-0001Oz-J5 for qemu-devel@nongnu.org; Fri, 10 May 2013 10:19:58 -0400 Date: Fri, 10 May 2013 15:17:59 +0100 From: "Daniel P. Berrange" Message-ID: <20130510141759.GO13475@redhat.com> References: <1368128600-30721-1-git-send-email-chegu_vinod@hp.com> <1368128600-30721-4-git-send-email-chegu_vinod@hp.com> <87y5bnc7a0.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87y5bnc7a0.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC PATCH v5 3/3] Force auto-convegence of live migration Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: quintela@redhat.com, Chegu Vinod , qemu-devel@nongnu.org, owasserm@redhat.com, pbonzini@redhat.com On Fri, May 10, 2013 at 08:07:51AM -0500, Anthony Liguori wrote: > Chegu Vinod 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 :|