Hopefully something similar to this can be upstreamed into the mainline Linux kernel — ideally whatever Google is using internally since it probably works well and is battle tested.

Its disappointing that AMD didn't bother to implement the 15H CPUID leaf that Intel added years ago to get the exact CPU TSC frequency. Yet AMD cared enough to add there own instruction(RDPRU) to get the values of APERF and MPERF in user mode.

As if that matters much in the current TSC frequency disaster... Very few Intel processors implement it completely or at all.

Intel claims to implement 15H CPUID but usually leaves the ART crystal HZ in ECX blank, which makes the other fields useless. Invariant timestamps are available on all x86_64 CPUs except K8, but trying to convert them to nanoseconds is an even bigger shit show than clock_gettime.

FD: My employer's blog.

I guess it shouldn't surprise me given the number of Linux and LLVM developers present at Google, but it always blows my mind a bit to see these kinds of internal changes form the basis of correct/sound results from tools like X-Ray.

> Additionally, the maximum clock speed, accessible in Linux via /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq, is not available in cloud-based or other virtualized environments.

Why? To prevent side-channel attacks?

The device is populated by the cpu_freq driver, which is used to control frequency scaling. Most cloud environments have shared tenancy and disable the feature to ensure one user can’t scale down the CPU for other tenants.

Is there no way to disable setting the CPU frequency?

I am not sure, but in my experience the driver is not present and not loadable.

Regardless, the max cpu frequency is not equal to tsc frequency on newer Intel CPUs, so the number is meaningless.