On Wed, 2021-09-08 at 13:51 -0400, Peter Xu wrote: > On Wed, Sep 08, 2021 at 06:30:50PM +0200, nsaenzju@xxxxxxxxxx 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? Will do. > Note there's a typo in subject too: > > oslat: rename cpu_mhz/cpu_hz to timer_mhz/cpu_hz > ^^^ timer Noted. > > > > 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. How about 'counter_[m]hz'? If not I'm fine with 'clock_[m]hz'. -- Nicolás Sáenz
