Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Hi,

On 2026-03-06 11:47:10 -0800, Lukas Fittl wrote:
> > 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.

I did some testing, and unfortunately it's not good enough. There are several
issues:

- The tsc counter starts earlier than the OS, by enough to make counter
initially not quite right. It's not that bad on a laptop with a quick boot
time, but on a server with slower bios time initialization (e.g. due to
training of more memory) it's worse.

- If the server is rebooted not through a hard reset (the typical default),
but through something like kexec (which does not go through bios again), the
tsc counter is not reset.

> 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.

Yea, I think we need a calibration loop, unfortunately. But I think it should
be doable to make it a lot quicker than waiting one second. I'm thinking of
something like a loop that measures the the clock cycles and relative time
(using clock_gettime()) since the start and does so until the frequency
estimate predicts the time results closely. I think should be a few 10s of
milliseconds at most.

> FWIW, I ended up getting an x86 machine to be able to test these
> things better, and got myself an AMD CPU.

Dedication...

> Well, turns out that my
> non-virtualized AMD CPU ("AMD Ryzen™ AI Max+ 395") does not provide
> the TSC frequency via CPUID, at all :(

I can repro that on a somewhat older Zen 4 (7840U) laptop CPU.

> Instead on newer AMD CPUs you can use an MSR to get the TSC frequency,
> see [2]

:(

Greetings,

Andres Freund