On Fri, Mar 6, 2026 at 11:22 AM Andres Freund <[email protected]> wrote:
> On 2026-03-03 10:22:42 -0800, Lukas Fittl wrote:
> > > But if we read files anyway, wouldn't just using
> > > /sys/devices/system/cpu/cpu0/cpufreq/base_frequency
> > > work?
> >
> > I tested this just now on an Azure VM (Standard D2s v3), and its
> > close, but unfortunately CPU frequency doesn't match the TSC frequency
> > (cpuinfo_max_freq is 2800000, scaling_cur_freq is 2496279, and TSC
> > frequency via MSR is 2793438 -- note that I didn't have base_frequency
> > on this VM). My understanding is that the TSC clock is virtualized in
> > HyperV and does not directly match the CPU frequency.
>
> :(
>
> It seems quite ridiculous that there's no cpuid to get the frequency of both
> virtualized and "real" tsc.
Agreed. I did find some efforts where folks tried to expose this
information to user space inspired by how Google apparently does it in
their internal kernel to support user space TSC programs (see [0] and
[1]), but I don't think that went anywhere, though I don't follow the
Kernel mailinglists, so maybe someone is working on that somewhere.
> > I'm also happy to take this out again - maybe we can get the
> > HyperV/Azure Linux folks to improve the Kernel side here to pass down
> > the TSC frequency without needing the MSR, and just not support it for
> > now.
>
> Yea, this doesn't seem worth it, it won't get used this way, I think.
Ack.
> But maybe we should just do the stupid thing and figure out the multiplier as
> such:
>
> ns_to_cycles = tsc_via_rdtsc / to_ns(clock_gettime(CLOCK_BOOTTIME))
>
> in some quick experiments that ends up with a very good estimate. There would
> have to be an awful long gap between the rdtsc and clock_gettime() computation
> for the frequency to be meaningfully inaccurate.
I think as long as the TSC counter and the clock boottime start at the
same moment, that should work. But I'm not sure if we can rely on that
to be the case in virtualized environments? I can do some more
testing.
Alternatively, we could consider doing it like the Kernel does it for
its calibration loop, and wait 1 second of wall time, and then see how
far the TSC counter has advanced.
FWIW, I ended up getting an x86 machine to be able to test these
things better, and got myself an AMD CPU. Well, turns out that my
non-virtualized AMD CPU ("AMD Ryzen™ AI Max+ 395") does not provide
the TSC frequency via CPUID, at all :(
Instead on newer AMD CPUs you can use an MSR to get the TSC frequency,
see [2] -- or calibrate against another time source (which I think we
should do).
Thanks,
Lukas
[0]: https://github.com/trailofbits/tsc_freq_khz
[1]:
https://blog.trailofbits.com/2019/10/03/tsc-frequency-for-all-better-profiling-and-benchmarking/
[2]:
https://github.com/jdmccalpin/low-overhead-timers/issues/1#issuecomment-1668472748
--
Lukas Fittl
