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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
