From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751822AbcFGBYP (ORCPT ); Mon, 6 Jun 2016 21:24:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46804 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750788AbcFGBYN (ORCPT ); Mon, 6 Jun 2016 21:24:13 -0400 Message-ID: <1465262649.16365.151.camel@redhat.com> Subject: Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug From: Rik van Riel To: Paolo Bonzini , Peter Zijlstra , Wanpeng Li Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Wanpeng Li , Ingo Molnar , Thomas Gleixner , Frederic Weisbecker , Radim Date: Mon, 06 Jun 2016 21:24:09 -0400 In-Reply-To: References: <1464868639-8924-1-git-send-email-wanpeng.li@hotmail.com> <20160602120023.GC3190@twins.programming.kicks-ass.net> <1464875988.16365.119.camel@redhat.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-D9Zt2KN60lwih7+3H6Ea" Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 07 Jun 2016 01:24:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-D9Zt2KN60lwih7+3H6Ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-06-06 at 15:40 +0200, Paolo Bonzini wrote: >=20 > On 02/06/2016 15:59, Rik van Riel wrote: > >=20 > > If a guest is saved to disk and later restored (eg. after > > a host reboot), or live migrated to another host, I would > > expect to get totally disjoint steal time statistics from > > the "new run" of the guest (which is the same run of the > > guest OS). > Why?=C2=A0=C2=A0The preexisting guest steal time is always added to by > KVM, so the time won't restart from zero. >=20 > Continuing the previous count on CPU hot-unplug followed by hot-plug > is less obvious, but I think it's overall the right thing to do. >=20 > In fact, I was going to test a patch this week as simple as this: >=20 > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > index eea2a6f72b31..1ef5e48b3a36 100644 > --- a/arch/x86/kernel/kvm.c > +++ b/arch/x86/kernel/kvm.c > @@ -301,8 +301,6 @@ static void kvm_register_steal_time(void) > =C2=A0 if (!has_steal_clock) > =C2=A0 return; > =C2=A0 > - memset(st, 0, sizeof(*st)); > - > =C2=A0 wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | > KVM_MSR_ENABLED)); By removing the memset from initial bootup allocation, can't that cause the steal time to "increase by a ludicrous amount" the very first time it is compared with the arch independent value in the scheduler code? In other words, would removal of the memset result in still requiring Wanpeng's patch? What am I overlooking? Is there something preventing a non-zero value right at the beginning? Also, is there a chance of ending up with a non-zero bit in the seqcount if the memset is removed? --=20 All Rights Reversed. --=-D9Zt2KN60lwih7+3H6Ea Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXViI5AAoJEM553pKExN6Dc4AH/iW4bFvKdywmLzW+vh23F2eP AVNgTYDJYhcm9Y/WdNP+TuKxH/NI8qPEhUNJqVz6iFTEJqhFgPHjZdXQXsBRpoHq q8ErALFX9iBIFPiZRLvojf4jych23Fod25LDUCrcgxihXdSFC2sdnZeRx/1D7A5S J13D1Nupn9ofeHnKuay97YsXnGWDzVdFPOg0fpyGa5DzVoAleX6jusLQZZ4/CZEd Zbw9J3Gspf3huQ7uHvwe65s4X5RggDOR/uszgKJtf7C1+4rAyjDZkHapluWnq5+M PwNaFroGPnJY1por2hY5XHczBsGQqj2GJtfKPbl/GgL/s6WaJ7yXmfiFd8jNFG0= =oVYK -----END PGP SIGNATURE----- --=-D9Zt2KN60lwih7+3H6Ea--