On 11.03.2022 13:03, Roger Pau Monné wrote: > On Mon, Feb 14, 2022 at 10:24:49AM +0100, Jan Beulich wrote: >> Calibration logic assumes that the platform timer (HPET or ACPI PM >> timer) and the TSC are read at about the same time. This assumption may >> not hold when a long latency event (e.g. SMI or NMI) occurs between the >> two reads. Reduce the risk of reading uncorrelated values by doing at >> least four pairs of reads, using the tuple where the delta between the >> enclosing TSC reads was smallest. From the fourth iteration onwards bail >> if the new TSC delta isn't better (smaller) than the best earlier one. >> >> Signed-off-by: Jan Beulich <[email protected]> > > Reviewed-by: Roger Pau Monné <[email protected]>
Thanks. >> --- >> When running virtualized, scheduling in the host would also constitute >> long latency events. I wonder whether, to compensate for that, we'd want >> more than 3 "base" iterations, as I would expect scheduling events to >> occur more frequently than e.g. SMI (and with a higher probability of >> multiple ones occurring in close succession). > > That's hard to tell, maybe we should make the base iteration count > settable from the command line? As a last resort (if people observe problems) - maybe. It's not clear to me though on what basis an admin would choose another value. Jan
