From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] live migration vs device assignment (motivation) Date: Tue, 29 Dec 2015 18:46:30 +0200 Message-ID: <20151229184426-mutt-send-email-mst@redhat.com> References: <20151210101840.GA2570@work-vm> <566961C1.6030000@gmail.com> <20151210114114.GE2570@work-vm> <56698E68.5040207@intel.com> <566D9320.8000209@intel.com> <567CEA53.5030601@intel.com> <20151225140336-mutt-send-email-mst@redhat.com> <56817476.8080607@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Duyck , "Dr. David Alan Gilbert" , Yang Zhang , qemu-devel@nongnu.org, "Tantilov, Emil S" , kvm@vger.kernel.org, Ard Biesheuvel , aik@ozlabs.ru, "Skidmore, Donald C" , quintela@redhat.com, "Dong, Eddie" , "Jani, Nrupal" , Alexander Graf , Blue Swirl , cornelia.huck@de.ibm.com, Alex Williamson , kraxel@redhat.com, Anthony Liguori , amit.shah@redhat.com, Paolo Bonzini , "Rustad, Mark D" , lcapitulino@redhat.com, Or Gerlitz To: "Lan, Tianyu" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50423 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753200AbbL2Qqi (ORCPT ); Tue, 29 Dec 2015 11:46:38 -0500 Content-Disposition: inline In-Reply-To: <56817476.8080607@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote: > > > On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote: > >As long as you keep up this vague talk about performance during > >migration, without even bothering with any measurements, this patchset > >will keep going nowhere. > > > > I measured network service downtime for "keep device alive"(RFC patch V1 > presented) and "put down and up network interface"(RFC patch V2 presented) > during migration with some optimizations. > > The former is around 140ms and the later is around 240ms. > > My patchset relies on the maibox irq which doesn't work in the suspend state > and so can't get downtime for suspend/resume cases. Will try to get the > result later. Interesting. So you sare saying merely ifdown/ifup is 100ms? This does not sound reasonable. Is there a chance you are e.g. getting IP from dhcp? If so that is wrong - clearly should reconfigure the old IP back without playing with dhcp. For testing, just set up a static IP. > > > > > > > >There's Alex's patch that tracks memory changes during migration. It > >needs some simple enhancements to be useful in production (e.g. add a > >host/guest handshake to both enable tracking in guest and to detect the > >support in host), then it can allow starting migration with an assigned > >device, by invoking hot-unplug after most of memory have been migrated. > > > >Please implement this in qemu and measure the speed. > > Sure. Will do that. > > >I will not be surprised if destroying/creating netdev in linux > >turns out to take too long, but before anyone bothered > >checking, it does not make sense to discuss further enhancements. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDxQ3-0007mp-8N for qemu-devel@nongnu.org; Tue, 29 Dec 2015 11:46:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDxPz-0006bG-7j for qemu-devel@nongnu.org; Tue, 29 Dec 2015 11:46:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDxPz-0006b6-1q for qemu-devel@nongnu.org; Tue, 29 Dec 2015 11:46:39 -0500 Date: Tue, 29 Dec 2015 18:46:30 +0200 From: "Michael S. Tsirkin" Message-ID: <20151229184426-mutt-send-email-mst@redhat.com> References: <20151210101840.GA2570@work-vm> <566961C1.6030000@gmail.com> <20151210114114.GE2570@work-vm> <56698E68.5040207@intel.com> <566D9320.8000209@intel.com> <567CEA53.5030601@intel.com> <20151225140336-mutt-send-email-mst@redhat.com> <56817476.8080607@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56817476.8080607@intel.com> Subject: Re: [Qemu-devel] live migration vs device assignment (motivation) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Lan, Tianyu" Cc: Yang Zhang , "Tantilov, Emil S" , kvm@vger.kernel.org, aik@ozlabs.ru, qemu-devel@nongnu.org, Alexander Duyck , lcapitulino@redhat.com, Blue Swirl , kraxel@redhat.com, "Rustad, Mark D" , quintela@redhat.com, "Skidmore, Donald C" , Alexander Graf , Or Gerlitz , "Dr. David Alan Gilbert" , Alex Williamson , Anthony Liguori , cornelia.huck@de.ibm.com, Ard Biesheuvel , "Dong, Eddie" , "Jani, Nrupal" , amit.shah@redhat.com, Paolo Bonzini On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote: > > > On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote: > >As long as you keep up this vague talk about performance during > >migration, without even bothering with any measurements, this patchset > >will keep going nowhere. > > > > I measured network service downtime for "keep device alive"(RFC patch V1 > presented) and "put down and up network interface"(RFC patch V2 presented) > during migration with some optimizations. > > The former is around 140ms and the later is around 240ms. > > My patchset relies on the maibox irq which doesn't work in the suspend state > and so can't get downtime for suspend/resume cases. Will try to get the > result later. Interesting. So you sare saying merely ifdown/ifup is 100ms? This does not sound reasonable. Is there a chance you are e.g. getting IP from dhcp? If so that is wrong - clearly should reconfigure the old IP back without playing with dhcp. For testing, just set up a static IP. > > > > > > > >There's Alex's patch that tracks memory changes during migration. It > >needs some simple enhancements to be useful in production (e.g. add a > >host/guest handshake to both enable tracking in guest and to detect the > >support in host), then it can allow starting migration with an assigned > >device, by invoking hot-unplug after most of memory have been migrated. > > > >Please implement this in qemu and measure the speed. > > Sure. Will do that. > > >I will not be surprised if destroying/creating netdev in linux > >turns out to take too long, but before anyone bothered > >checking, it does not make sense to discuss further enhancements.