Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1415798
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug |
| Date | 2016-06-07 09:40 +0200 |
| Message-ID | <rHjMe-897-25@gated-at.bofh.it> (permalink) |
| References | <rFzs5-5tU-3@gated-at.bofh.it> <rFzBM-5Mk-27@gated-at.bofh.it> <rFBtU-6Tw-15@gated-at.bofh.it> <rH34J-5B9-3@gated-at.bofh.it> <rHe09-4kp-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 07/06/2016 03:24, Rik van Riel wrote: > On Mon, 2016-06-06 at 15:40 +0200, Paolo Bonzini wrote: >> >> On 02/06/2016 15:59, Rik van Riel wrote: >>> >>> 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? The preexisting guest steal time is always added to by >> KVM, so the time won't restart from zero. >> >> 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. >> >> In fact, I was going to test a patch this week as simple as this: >> >> 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) >> if (!has_steal_clock) >> return; >> >> - memset(st, 0, sizeof(*st)); >> - >> 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? The percpu area is initialized to zero, isn't it? Paolo > 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? >
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Wanpeng Li <kernellwp@gmail.com> - 2016-06-02 14:00 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Peter Zijlstra <peterz@infradead.org> - 2016-06-02 14:10 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Rik van Riel <riel@redhat.com> - 2016-06-02 16:10 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Wanpeng Li <kernellwp@gmail.com> - 2016-06-03 07:40 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Paolo Bonzini <pbonzini@redhat.com> - 2016-06-06 15:50 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Wanpeng Li <kernellwp@gmail.com> - 2016-06-07 00:50 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Rik van Riel <riel@redhat.com> - 2016-06-07 03:30 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Wanpeng Li <kernellwp@gmail.com> - 2016-06-07 09:40 +0200
Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug Paolo Bonzini <pbonzini@redhat.com> - 2016-06-07 09:40 +0200
csiph-web