On Tue, Mar 3, 2026 at 9:09 AM Andres Freund <[email protected]> wrote: > On 2026-03-03 02:29:06 -0800, Lukas Fittl wrote: > > - Added support for HyperV hypervisor by reading the TSC frequency > > MSR. This allows Azure Linux VMs to work as well, and in my test gives > > a similar speed up with RDTSC like reported on AWS. Only annoyance is > > that to enable it you have to make /dev/cpu/0/msr readable ("setcap > > cap_sys_rawio=ep" on the binary that accesses it + give the user/group > > access to the device file) > > I rather doubt that giving even just read access to MSRs to unprivileged > userspace processes is a good idea.
Yeah, that's fair - the interface here is rather crude, and I agree that MSR access is problematic for non-root. > 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. 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. 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). Thanks, Lukas -- Lukas Fittl
