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.
signature.asc
Description: This is a digitally signed message part
