[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <974330607.1641549.1471072722360.JavaMail.zimbra@redhat.com>
Date: Sat, 13 Aug 2016 03:18:42 -0400 (EDT)
From: Paolo Bonzini <pbonzini@...hat.com>
To: Rik van Riel <riel@...hat.com>
Cc: Wanpeng Li <kernellwp@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Wanpeng Li <wanpeng.li@...mail.com>,
Thomas Gleixner <tglx@...utronix.de>,
Radim Krcmar <rkrcmar@...hat.com>,
Mike Galbraith <efault@....de>
Subject: 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
Powered by blists - more mailing lists