[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/2] x86/time: improve TSC / CPU freq calibration accuracy
On 12.01.2022 11:53, Roger Pau Monné wrote: > On Wed, Jan 12, 2022 at 09:56:12AM +0100, Jan Beulich wrote: >> While the problem report was for extreme errors, even smaller ones would >> better be avoided: The calculated period to run calibration loops over >> can (and usually will) be shorter than the actual time elapsed between >> first and last platform timer and TSC reads. Adjust values returned from >> the init functions accordingly. >> >> On a Skylake system I've tested this on accuracy (using HPET) went from >> detecting in some cases more than 220kHz too high a value to about >> ±2kHz. On other systems (or on this system, but with PMTMR) the original >> error range was much smaller, with less (in some cases only very little) >> improvement. >> >> Reported-by: James Dingwall <james-xen@xxxxxxxxxxxxxx> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > > Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Thanks. >> I'm afraid I don't see a way to deal with the same issue in init_pit(). >> In particular the (multiple) specs I have to hand don't make clear >> whether the counter would continue counting after having reached zero. >> Obviously it wouldn't help to check this on a few systems, as their >> behavior could still be implementation specific. > > We could likely set the counter to the maximum value it can hold > and then perform reads in a loop (like it's done for HPET or the PM > timers) and stop when start - target is reached. Not a great solution > either. Not the least because reading back the counter from the PIT requires multiple port operations, i.e. is overall quite a bit slower. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |