From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dr. David Alan Gilbert" Subject: Re: [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save Date: Mon, 7 Nov 2016 13:08:28 +0000 Message-ID: <20161107130827.GD2054@work-vm> References: <20161104094322.GA16930@amt.cnet> <20161104152522.GC5388@potion> <20161104170750.GA4346@amt.cnet> <20161104173918.GB32170@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel , Paolo Bonzini , Juan Quintela , Eduardo Habkost To: Radim =?utf-8?B?S3LEjW3DocWZ?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60536 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752597AbcKGNIc (ORCPT ); Mon, 7 Nov 2016 08:08:32 -0500 Content-Disposition: inline In-Reply-To: <20161104173918.GB32170@potion> Sender: kvm-owner@vger.kernel.org List-ID: * Radim Krčmář (rkrcmar@redhat.com) wrote: > 2016-11-04 15:07-0200, Marcelo Tosatti: > > On Fri, Nov 04, 2016 at 04:25:23PM +0100, Radim Krčmář wrote: > >> > + /* > >> > + * Transition from VM-running to VM-stopped via migration? > >> > + * Record when the VM was stopped. > >> > + */ > >> > + > >> > + if (state == RUN_STATE_FINISH_MIGRATE && > >> > + !migration_in_postcopy(migrate_get_current())) { > >> > + clock_gettime(CLOCK_MONOTONIC, &s->t_aftervmstop); > >> > >> How big (more like small) was the clock delta between here and > >> kvmclock_pre_save with postcopy? > >> > >> Thanks. > > > > qemu-system-x86_64: postcopy_ram_supported_by_host: userfaultfd not > > available: Function not implemented > > > > But should be about the same as precopy+this patch (guess as i don't > > know the postcopy path). > > I was wondering about the improvement we could achieve by not excluding > postcopy from the time fixup. (i.e. how much time elapses between > pausing and migrating the vm in postcopy) > > I would also guess that it is not significant. It can add up, so it would be useful to be able to do this trick. We have to calculate and send some 'discard maps' that can take some time, especially on larger VMs, and we also have to serialise the state of all non-RAM devices, so if you have a lot of other emulated devices it can take a bit more time. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK