On Sat, Jan 09, 2021 at 12:52:22PM -0600, Dale Rahn wrote:
> The 'magic' here was that MD code could choose to implement statclock (and
> set stathz appropriately), or MD code could not care about the multiple
> statclock/hardclock interfaces into the scheduler. Also some clock drivers
> on a platform could enable split hardclock/statclock where others did not.
Gotcha.
> Back near the beginning of OpenBSD platforms existed that had no higher
> precision clock than that timer interrupt, and nothing existed to even
> approximate higher precision (eg cycle counters or instruction counters).
My understanding is that HZ=100 was a practical choice because the
machines of the day could not reliably drive a faster clock interrupt.
> Some clock drivers have a separate timer/interrupt or separate 'event'
> tracked to schedule the stat() event. These platforms may also
> (dynamically) change the stathz clock when profiling is enabled/disabled.
> This is implemented in arm64 in agtimer_setstatclockrate()
My hope is to make this the case for *all* platforms with MI code.
More on that in a later patch. You'll be CC'd.
> Any clock driver that directly calls statclock() should make certain to
> stathz (and profhz) appropriately, as no assumptions to it's rate/frequency
> should be assumed.
Do we need to properly set stathz for each platform in *this* diff?
Or can it wait?
I was hoping to do a sweep of the tree in a later patch and ensure
that stathz is non-zero everywhere and simultaneously remove code like
this:
int realstathz = stathz ? stathz : hz;
Near as I can tell, stathz doesn't need to be nonzero for statclock()
to work correctly. Also, setstatclockrate() doesn't even run unless
stathz is non-zero, so there are no issues with the profiling clock
stuff yet.
> This isn't to say that removing the stathz== 0 magic should not be done,
> but if done, make certain that stathz and profhz are properly
> updated/configured.
