On Sun, Aug 23, 2020 at 11:45:22PM -0500, Scott Cheloha wrote:
>
> [...]
>
> > > This patch (or something equivalent) is a prerequisite to running the
> > > lapic timer in oneshot or TSC deadline mode. Using the lapic timer to
> > > implement delay(9) when it isn't running in periodic mode is too
> > > complicated. However, using the i8254 for delay(9) is too slow. We
> > > need an alternative.
> >
> > Hmm, but what are we going to use on machines where the TSC isn't
> > constant/invariant?
>
> Probably fall back on the i8254? Unless someone wants to add yet
> another delay(9) implementation to amd64...
>
> > In what respect is the i8254 too slow? Does it take more than a
> > microsecond to read it?
>
> On my machine, the portion of gettick() *within* the mutex runs in ~19
> microseconds.
>
> That's before any overhead from mtx_enter(9). I think having multiple
> threads in delay(9) should be relatively rare, but you have to keep
> that in mind.
>
> No idea what the overhead would look like on real hardware. I'm
> pretty sure my i8254 is emulated.
>
> > We could use the HPET I suppose, whic may be a bit better.
>
> It's better. No mutex. On my machine it takes ~11 microseconds.
> It's a start.
Hmmm, now I'm worried I have screwed something up or misconfigured
something.
It doesn't seem right that it would take 20K cycles to read the HPET
on this machine.
Am I way off? Or is 20K actually a reasonable number?
For comparison, lapic_gettick() completes in... 80 nanoseconds (?) on
the same machine. Relevant sysctls:
$ sysctl hw.{model,setperf,perfpolicy} machdep.{tscfreq,invarianttsc}
hw.model=Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
hw.setperf=100
hw.perfpolicy=high
machdep.tscfreq=2112000000
machdep.invarianttsc=1
... if it really takes that long, then "high precision" is a bit of a
misnomer.
