Re: TSC improvement

[Andrew Doran <ad%netbsd.org@localhost>]

On Tue, Jun 09, 2020 at 05:16:27PM +0000, Taylor R Campbell wrote:

> It's great to see improvements to our calibration of the TSC (and I
> tend to agree that cpu_counter should be serializing, so that, e.g.,
> cpu_counter(); ...; cpu_counter() reliably measures time taken in the
> ellipsis).
> 
> At the same time, I wonder whether we should _also_:
> 
> 1. Modify the tsc timecounter so that it uses a global atomic to
>    ensure that there is a global view of time as counted by the tsc.

A long time ago we used to do something quite like this for x86 but it
worked poorly which is somewhat understandable because it's really difficult
to get something like that right.  (Which reminds me someone posted a patch
for kern_cctr.c for alpha a couple of years ago.)

>    This is what the timecounter(9) API per se expects of timecounters,
>    and right now tsc (along with various other per-CPU cycle counters)
>    fails to guarantee that.

Howso, do you see a bug?  I think it's okay.  The TSC is only used for the
timecounter where it's known that it's insensitive to core speed variations
and is driven by PLL related to the bus clock.  Fortunately that means most
x86 systems, excepting a window of some years from roughly around the time
of the Pentium 4 onwards.

Cheers,
Andrew

> 2. Introduce an API for a local timecounter -- a per-CPU timecounter
>    that never goes backwards on a single CPU, but:
>    (a) measures units of wall clock time, unlike cpu_counter();
>    (b) need not be synchronized between CPUs; and
>    (c) may be cheaper to read than a global timecounter.
>    We could then use that for, e.g., rusage calculations.