From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3jfB-0003En-Eg for qemu-devel@nongnu.org; Mon, 07 Nov 2016 08:08:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3jf7-0005ze-HY for qemu-devel@nongnu.org; Mon, 07 Nov 2016 08:08:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58636) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c3jf7-0005we-BG for qemu-devel@nongnu.org; Mon, 07 Nov 2016 08:08:33 -0500 Date: Mon, 7 Nov 2016 13:08:28 +0000 From: "Dr. David Alan Gilbert" 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-Disposition: inline In-Reply-To: <20161104173918.GB32170@potion> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Radim =?utf-8?B?S3LEjW3DocWZ?= Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel , Paolo Bonzini , Juan Quintela , Eduardo Habkost * Radim Kr=C4=8Dm=C3=A1=C5=99 (rkrcmar@redhat.com) wrote: > 2016-11-04 15:07-0200, Marcelo Tosatti: > > On Fri, Nov 04, 2016 at 04:25:23PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99= wrote: > >> > + /* > >> > + * Transition from VM-running to VM-stopped via migration= ? > >> > + * Record when the VM was stopped. > >> > + */ > >> > + > >> > + if (state =3D=3D RUN_STATE_FINISH_MIGRATE && > >> > + !migration_in_postcopy(migrate_get_current())) { > >> > + clock_gettime(CLOCK_MONOTONIC, &s->t_aftervmstop); > >>=20 > >> How big (more like small) was the clock delta between here and > >> kvmclock_pre_save with postcopy? > >>=20 > >> Thanks. > >=20 > > qemu-system-x86_64: postcopy_ram_supported_by_host: userfaultfd not > > available: Function not implemented > >=20 > > But should be about the same as precopy+this patch (guess as i don't=20 > > know the postcopy path). >=20 > 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) >=20 > 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