On 25/01/2024 4:55 pm, Jan Beulich wrote: > Since the performance counters used for the NMI watchdog count non- > halted cycles, they may count at a rate higher than cpu_khz.
Is this in theory, or observed in practice? It is my understanding that perf counters count in P0 reference cycles, and not at the Turbo/CBS rate. > Thus the > watchdog tick may occur more frequently than invocations of the timer > if we don't account for the ratio between nominal and maximum CPU clock > speeds, which would be a problem in particular when "watchdog_timeout=1" > is in effect (for high enough ratios even larger timout values may pose > a problem). > > Leverage the so far display-only data we collect on newer Intel and AMD > CPUs. On older CPUs we just have to (continue to) hope that the default > frequency of 1 Hz is okay(-ish) to use. > > While adding the new variable, also move the (now adjacent) cpu_khz to > .data.ro_after_init. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > This renders the "log" in the function names somewhat stale, but I don't > think this strictly warrants renaming the functions right away. I'm not comfortable with this change. It's adding to a complicated timing problem, rather than simplifying it. The real problem we've got is that the NMI handler is guessing at the timeout by counting NMIs, not by actually counting time. There are several ways to fix this even with the current rendezvous logic. When the NMI handler can actually say "if ( NOW() - last > timeout )", then the exact frequently of NMIs becomes far less important. ~Andrew
