Re: [PATCH v10 7/7] x86/tsc: use tsc early

From: Thomas Gleixner
Date: Wed Jun 20 2018 - 06:43:08 EST


On Wed, 20 Jun 2018, Peter Zijlstra wrote:

> On Wed, Jun 20, 2018 at 01:52:10AM +0200, Thomas Gleixner wrote:
> > u64 native_sched_clock(void)
> > {
> > + if (static_branch_likely(&__use_tsc))
> > + return cycles_2_ns(rdtsc());
> >
> > + if (static_branch_unlikely(&tsc_early_enabled)) {
> > + if (tsc_early_sched_clock)
> > + return cycles_2_ns(rdtsc());
> > }
>
> I'm still puzzled by the entire need for tsc_early_enabled and all that.
> Esp. since both branches do the exact same thing:
>
> return cycles_2_ns(rdtsc());

Right. But up to the point where the real sched_clock initialization can be
done and the static keys can be flipped, there must be a way to
conditinally use TSC depending on availablility and early initialization.

We cannot make the __use_tsc key TRUE at conmpile timeunless we add an
extra conditional into that codepath which makes the whole static key moot.

So the second static key for the early stuff is TRUE and has the extra
conditional:

if (tsc_early_sched_clock)
return cycles_2_ns(rdtsc());

And that code path gets nuked with flipping the key to FALSE in the later
init code, so that in case of jiffies we do not have the extra conditional
in every sched_clock() invocation.

You might argue, that we shouldn't care becasue the jiffies case is just
the worst case fallback anyway. I wouldn't even disagree as those old
machines which have TSC varying with the CPU frequency really should not
matter anymore. Pavel might disagree of course.

Thanks,

tglx