Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1461308 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

On 10/08/2016 18:52, Rik van Riel wrote:
> Paolo, what is your opinion on this issue?
> 
> I can think of all kinds of ways in which guest and host might lose
> sync with steal time, from uninitialized values at boot, to guest
> pause, followed by save to disk, and reload, to live migration, to...

Guest and host _cannot_ lose sync because there is only one copy of the
values.  When the host wants to update the steal time value it just
reads the old value and writes the new value.  There cannot be a guest
pause, save to disk, live migration or whatever between these two steps
(and uninitialized values at boot are not how percpu values work).

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.

Paolo

[toc] | [next] | [standalone]

#1461336

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2016-08-12 at 18:33 +0200, Paolo Bonzini wrote:
> 
> On 10/08/2016 18:52, Rik van Riel wrote:
> > Paolo, what is your opinion on this issue?
> > 
> > I can think of all kinds of ways in which guest and host might lose
> > sync with steal time, from uninitialized values at boot, to guest
> > pause, followed by save to disk, and reload, to live migration,
> > to...
> 
> Guest and host _cannot_ lose sync because there is only one copy of
> the
> values.  When the host wants to update the steal time value it just
> reads the old value and writes the new value.  There cannot be a
> guest
> pause, save to disk, live migration or whatever between these two
> steps
> (and uninitialized values at boot are not how percpu values work).

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?

> 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.

-- 

All Rights Reversed.

[toc] | [prev] | [next] | [standalone]

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

> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web