From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uaovb-0005TH-Va for qemu-devel@nongnu.org; Fri, 10 May 2013 11:08:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uaova-0001or-GU for qemu-devel@nongnu.org; Fri, 10 May 2013 11:08:11 -0400 Received: from mail-oa0-f50.google.com ([209.85.219.50]:46089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uaova-0001om-C9 for qemu-devel@nongnu.org; Fri, 10 May 2013 11:08:10 -0400 Received: by mail-oa0-f50.google.com with SMTP id l20so2015594oag.23 for ; Fri, 10 May 2013 08:08:09 -0700 (PDT) From: Anthony Liguori In-Reply-To: <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> <20130510141759.GO13475@redhat.com> Date: Fri, 10 May 2013 10:08:05 -0500 Message-ID: <87li7mzxd6.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [RFC PATCH v5 3/3] Force auto-convegence of live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: quintela@redhat.com, Chegu Vinod , qemu-devel@nongnu.org, owasserm@redhat.com, pbonzini@redhat.com "Daniel P. Berrange" writes: > 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. 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 :|