From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2iSd-0001Z7-4P for qemu-devel@nongnu.org; Fri, 04 Nov 2016 13:39:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2iSZ-0007gf-74 for qemu-devel@nongnu.org; Fri, 04 Nov 2016 13:39:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56548) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c2iSZ-0007fX-1u for qemu-devel@nongnu.org; Fri, 04 Nov 2016 13:39:23 -0400 Date: Fri, 4 Nov 2016 18:39:18 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20161104173918.GB32170@potion> References: <20161104094322.GA16930@amt.cnet> <20161104152522.GC5388@potion> <20161104170750.GA4346@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161104170750.GA4346@amt.cnet> 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: Marcelo Tosatti Cc: kvm@vger.kernel.org, qemu-devel , "Dr. David Alan Gilbert" , Paolo Bonzini , Juan Quintela , Eduardo Habkost 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 w= rote: >> > + /* >> > + * 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). 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.