On Mon, Aug 24, 2020 at 01:55:45AM +0200, Mark Kettenis wrote: > > Date: Sun, 23 Aug 2020 18:11:12 -0500 > > From: Scott Cheloha <[email protected]> > > > > Hi, > > > > Other BSDs use the TSC to implement delay(9) if the TSC is constant > > and invariant. Here's a patch to add something similar to our kernel. > > If the TSC is fine as a timecounter it should be absolutely fine for > use as delay(). And we could even use if the TSC isn't synchronized > between CPUs.
Yep, it's nice. > > 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. > > As for the patch, it works for me here, though I'd appreciate a few > > tests. I admit that comparing function pointers is ugly, but I think > > this is as simple as it can be without implementing some sort of > > framework for "registering" delay(9) implementations and comparing > > them and selecting the "best" implementation. > > What about: > > if (delay_func == NULL) > delay_func = lapic_delay; Nah, can't do that. delay_func is initialized to i8254_delay(). Look in amd64/machdep.c. I'm curious what NetBSD and Dragonfly have done about this. Lemme look around. The whole "all the clocks on amd64 are slow or broken" issue isn't unique to us.
