Hi, 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. > 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. > An alternate idea could be to allow overriding the TSC frequency via a > GUC - then one could use the root user (or a setuid program) to get > the TSC frequency on Azure/HyperV via the MSR and pass it to Postgres > at start. But not sure that's worth the trouble, since it won't help > with environments that don't have a reliable TSC (e.g. Virtualbox, I > think). I don't think manually specifying it makes sense either. 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 was worried for a moment that the there would be issues with the tsc counter overflowing after a long uptime, but that doesn't seem a real issue if I did the math right (at a 10GHz tsc freq the time to overflow would be ~58 years). Greetings, Andres Freund
