[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1809180948570.3558@nanos.tec.linutronix.de>
Date: Tue, 18 Sep 2018 09:52:26 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: John Stultz <john.stultz@...aro.org>
cc: Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Matt Rickard <matt@...trans.com.au>,
Stephen Boyd <sboyd@...nel.org>,
Florian Weimer <fweimer@...hat.com>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
devel@...uxdriverproject.org,
Linux Virtualization <virtualization@...ts.linux-foundation.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Juergen Gross <jgross@...e.com>
Subject: Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case
On Mon, 17 Sep 2018, John Stultz wrote:
> On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski <luto@...nel.org> wrote:
> > Also, I'm not entirely convinced that this "last" thing is needed at
> > all. John, what's the scenario under which we need it?
>
> So my memory is probably a bit foggy, but I recall that as we
> accelerated gettimeofday, we found that even on systems that claimed
> to have synced TSCs, they were actually just slightly out of sync.
> Enough that right after cycles_last had been updated, a read on
> another cpu could come in just behind cycles_last, resulting in a
> negative interval causing lots of havoc.
>
> So the sanity check is needed to avoid that case.
Your memory serves you right. That's indeed observable on CPUs which
lack TSC_ADJUST.
@Andy: Welcome to the wonderful world of TSC.
Thanks,
tglx
Powered by blists - more mailing lists