Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
| От | Andres Freund |
|---|---|
| Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Дата | |
| Msg-id | p3ygm5nnefekhj6sfoanzwqygcz3edag7shblkidq47l3ys3r2@v2twclclhlwm обсуждение исходный текст |
| Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (David Geier <geidav.pg@gmail.com>) |
| Список | pgsql-hackers |
Hi, On 2025-09-01 12:36:24 +0200, David Geier wrote: > > Open questions I have: > > - Could we rely on checking whether the TSC timesource is invariant (via > > CPUID), instead of relying on Linux choosing it as a clocksource? > > Why do you want to do that? Are you concerned that Linux might pick a > different clock source even though invariant TSC is available? Not sure about Lukas, but I'm slightly concerned about making this a linux specific mechanism unnecessarily. > We could code our own check but looking at the Linux kernel code, this > is a bit more involved if we want to do it completely right. They check > e.g. if the TSC is also synchronized across different CPUs, which is not > the case if they're on different chassis (see unsynchronized_tsc() -> > apic_is_clustered_box()). I think Linux has higher fidelity requirements than our instrumentation usage - with linux an inaccurate clock would lead to broken timers, wrong wall clock etc, whereas for us it's just a skewed instrumentation result. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: