Re: TSC clock going backwards on suspend/resume

[Andrew Doran <ad%NetBSD.org@localhost>]

On Wed, Feb 25, 2009 at 08:13:53PM +0100, Matthias Drochner wrote:

> ad%NetBSD.org@localhost said:
> > > It is not explained what the "drift" and "skew" are about,
> > It's implied by the words used. It could use a comment block. Skew is
> > an observed offset between CPUs
> 
> OK, I believe I understand the code now... It could be noted that
> it is the difference for each AP relative to the BP, sampled
> during the *sync* process.

Right.
 
> > Drift is the process of the offset changing over time.
> 
> The "over time" is a bit dubious here afais -- it is taken
> only once, over a random interval and not weighted. So I think
> it is only suitable to detect spontaneous misbehaviour, not to
> measure a real clock frequency difference.
> Does this happen in practice?

It's there as a safety measure. We only enable TSC as timecounter where it's
reported safe by the CPU vendor. During autoconfiguration, APs are put into
a power saving state while waiting to be brought online by the BP. If the
TSC is dodgy, this may make it drift. The threshold for failing the TSC as
timecounter is quite low (250 clock cycles worth of drift). Note that if the
system receives an SMI during calibration it may fail, but there is not a
whole lot we can do about that.

Also bus, cache and TLB effects will thwart any attempt to calibrate the
TSCs once the system is up and running, so we are limited in what we can do.

> > > *sync* functions are usually called twice
> > It's to elide major cache effects. The result from the first pass is
> > discarded.
> 
> Would you mind if I put the reprtition into the functions
> instead of the callers, and also add calls to the acpi
> wakeup?

That sounds fine to me.

Thanks,
Andrew