On 18/01/2022 08:50, Jan Beulich wrote:
On 13.01.2022 14:41, 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]>
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).
Should Xen be continually or periodically recalibrating? Rather than
trying to get it perfect at the start of day?
You may also be able to find inspiration from the design or
implementation of the Precision Time Protocol which has to similarly
filter out outliers due to transmission delays.
David
