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

[Thomas Gleixner]

On Wed, 20 Jun 2018, Peter Zijlstra wrote:
> On Wed, Jun 20, 2018 at 12:42:40PM +0200, Thomas Gleixner wrote:
> > On Wed, 20 Jun 2018, Peter Zijlstra wrote:
> 
> > > 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.
> 
> Ah, so we want to flip keys early, can be done, see below.
> 
> > 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.
> 
> You forgot (rightfully) that we even use TSC on those !constant
> machines, we adjust the cycles_2_ns thing from the cpufreq notifiers.
> 
> The only case we should _ever_ use that jiffies callback is when TSC
> really isn't there. Basically, if we kill notsc, we could make
> native_sched_clock() := cycles_2_ns(rdtsc()) (for CONFIG_X86_TSC), the
> end.
> 
> No static keys, nothing.

So much for the theory. There are CPUs out there where you can't figure out
the TSC frequency which in turn needs to discard TSC as well. Yes, it's all
utter crap....

> That said; flipping static keys early isn't hard. We should call
> jump_label_init() early, because we want the entries sorted and the
> key->entries link set. It will also replace the GENERIC_NOP5_ATOMIC
> thing, which means we need to also do arch_init_ideal_nop() early, but
> since that is pure CPUID based that should be doable.

Yes, that should work and then we'd just have a single static key.

Thanks,

	tglx