Hi Peter, thanks for having a look at this! And sorry in advance for the long documentation dump. 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. 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
