Re: [PATCH] time,virt: resync steal time when guest & host lose sync

From	Paolo Bonzini <pbonzini@redhat.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH] time,virt: resync steal time when guest & host lose sync
Date	2016-08-13 09:20 +0200
Message-ID	<s5BoB-67U-1@gated-at.bofh.it> (permalink)
References	(3 earlier) <s4oD8-5EB-49@gated-at.bofh.it> <s4oMO-5I4-21@gated-at.bofh.it> <s4G70-8uN-67@gated-at.bofh.it> <s5nEZ-44y-1@gated-at.bofh.it> <s5oro-4ES-27@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

> There is one copy of paravirt_steal_clock(smp_processor_id()),
> but what keeps it in sync with this_rq()->prev_steal_time?
> 
> Is it something simple like them both being zeroed out when
> the structures are first allocated at boot time?

Yes, more precisely both of them being equal when the MSR is
written to.  They are just memory locations so they remain in
sync across pause, migration and the like, and prev_steal_time
is only ever updated with a previous value of paravirt_steal_clock().

> > Your hypothesis of lost ticks makes the most sense to me, and then
> > changing the argument to ULONG_MAX is the right thing to do.
> 
> I sent out a patch that just removes the parameter instead,
> and documents why steal_account_process_time can encounter
> more elapsed time than the calling functions expected.

Good, thanks!

Paolo

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH] time,virt: resync steal time when guest & host lose sync Paolo Bonzini <pbonzini@redhat.com> - 2016-08-12 18:40 +0200
  Re: [PATCH] time,virt: resync steal time when guest & host lose sync Rik van Riel <riel@redhat.com> - 2016-08-12 19:30 +0200
    Re: [PATCH] time,virt: resync steal time when guest & host lose  sync Paolo Bonzini <pbonzini@redhat.com> - 2016-08-13 09:20 +0200

csiph-web