Re: [PATCH 1/3] oslat: rename cpu_mhz/cpu_hz to timer_mhz/cpu_hz

[Peter Xu <peterx@redhat.com>]

On Wed, Sep 08, 2021 at 06:30:50PM +0200, nsaenzju@redhat.com wrote:
> Hi Peter, thanks for having a look at this! And sorry in advance for the long
> documentation dump.

It's actually great to reference the documents, thanks for that. I'd appreciate
if you can also add some more explanation into commit message too, may not be
the full copy-paste of the document though, just with the explicit x86/ppc
examples to show this is not for arm-only idea?

Note there's a typo in subject too:

  oslat: rename cpu_mhz/cpu_hz to timer_mhz/cpu_hz
                                            ^^^ timer

> 
> On Wed, 2021-09-08 at 10:40 -0400, Peter Xu wrote:
> > Hello, Nicolas,
> > 
> > On Wed, Sep 08, 2021 at 12:02:07PM +0200, Nicolas Saenz Julienne wrote:
> > > 'cpu_mhz' in oslat actually represents the frequency at which the high
> > > frequency timer we measure with ticks. There is no need for it to match
> > > the CPU frequency, nor will do on all supported architectures. So rename
> > > it to 'timer_mhz' in order to better match reality.
> > 
> > But right now "cpu_mhz" is indeed the cpu frequency per mhz, isn't it?  As I
> > believe that's how "time stamp counter" defined on x86. :)
> 
> Sadly I don't think this is really the case. In some cases TSC might match
> CPU's base frequency, but it depends on the processor family and other
> factors[1]. Also, the same applies for PPC64[2].
> 
> My reading is that, in general, we are only safe to assume we're getting a
> constant monotonically increasing timer unrelated from CPU's actual frequency.
> 
> > I don't know what's the corresponding register for aarch64 to read the
> > processor clock cycles out, I did a quick google and it tells me PMCCNTR, but
> > I've no solid idea.  Or do you mean for some reason we can't read that info out
> > from aarch64?
> 
> Sadly PMCCNTR isn't available at Exception Level 0 (user-space) and AFAIU we're
> stuck with CNTVCT_EL0.

Fair enough.

Though I still think the name "timer" is vague - timer normally means to me
that there's a setup+invoke procedure, and there can be overhead.  While all
these monotonically increasing registers (either real or virtual) should not
have those, we just read some counter out.

How about "clock_[m]hz"?  It does not necessarily to be a property of the
processor, but it's indeed a clock at least in electronics terms.

Thanks,

> 
> Regards,
> Nicolas
> 
> [1] Intel TRM Vol 3B, 17.17 Time Stamp Counter
> 
> Processor families increment the time-stamp counter differently:
> 
> • For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
>   processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
>   and for P6 family processors: the time-stamp counter increments with every
>   internal processor clock cycle. The internal processor clock cycle is
>   determined by the current core-clock to bus-clock ratio. Intel® SpeedStep®
>   technology transitions may also impact the processor clock.
> 
> • For Pentium 4 processors, Intel Xeon processors (family [0FH], models [03H
>   and higher]); for Intel Core Solo and Intel Core Duo processors (family [06H],
>   model [0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo
>   processors (family [06H], model [0FH]); for Intel Core 2 and Intel Xeon
>   processors (family [06H], DisplayModel [17H]); for Intel Atom processors
>   (family [06H], DisplayModel [1CH]): the time-stamp counter increments at a
>   constant rate. That rate may be set by the maximum core-clock to bus-clock
>   ratio of the processor or may be set by the maximum resolved frequency at which
>   the processor is booted. The maximum resolved frequency may differ from the
>   processor base frequency, see Section 18.7.2 for more detail. On certain
>   processors, the TSC frequency may not be the same as the frequency in the brand
>   string. The specific processor configuration determines the behavior. Constant
>   TSC behavior ensures that the duration of each clock tick is uniform and
>   supports the use of the TSC as a wall clock timer even if the processor core
>   changes frequency. This is the architectural behavior moving forward.
> 
> The specific processor configuration determines the behavior. Constant TSC
> behavior ensures that the duration of each clock tick is uniform and supports
> the use of the TSC as a wall clock timer even if the processor core changes
> frequency. This is the architectural behavior moving forward.
> 
> [2] From __ppc_get_timebase() manpages: The Time Base Register is a 64-bit
> register provided by Power Architecture processors. It stores a monotonically
> incremented value that is updated at a system-dependent frequency that may be
> different from the processor frequency.
> 
> Note that glibc's __ppc_get_timebase() and oslat's ppc frc() implementations
> are the same:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/sys/platform/ppc.h;h=8b0a66de1b93a56e3edf56c31a0c1505d7a8fc08;hb=HEAD#l27
> 

-- 
Peter Xu