Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

[Ingo Molnar <mingo@kernel.org>]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Wed, 3 Jun 2015, Linus Torvalds wrote:
> > On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > > Given that Windows relies on the HPET for timekeeping, it might get more 
> > > attention than the PIT?
> > 
> > Does Windows actually do that? Becuase if so, that's just about the strongest 
> > argument for HPET there is - it's likely to work, and the frequency is likely 
> > to be correct.
> 
> At least it used to. Not sure if it still does.

So I googled around a bit, and it's not as clear-cut as I thought initially: it 
appears that if the BIOS enables the HPET then modern Windows (Windows 7 and 
later) will use it, but there are problems and Windows XP (the largest installed 
base) used the TSC+acpipm. (two other lovely clocks)

> > We've had issues with HPET, but for calibration it might very well be the 
> > right thing to do.
> 
> Right. The issues we had were on the clock events side caused by the match 
> register delayed writes. I've never seen a bug report about the frequency being 
> completely wrong, except for crap values which we filter out. Though, HPET 
> period can be off by more than 500ppm, but I don't think that matters anymore 
> for timekeeping as we switch to TSC only after the long term calibration. The 
> quick calibration is just for getting the TSC frequency roughly correct for 
> udelay.

Yes - so the frequency being off due to production variances (or sheer firmware 
incompetence) isn't a big deal in itself: having boot-to-boot jitter during fast 
calibration would be, and that's the big question.

The nice thing about the PIT calibration is that it usually provides very little 
jitter, so that driver delays/etc. are as boot-to-boot identical as possible.

Anyway, the HPET might be worth an attempt - but I'd not be surprised if we 
discovered another rotten apple ...

Thanks,

	Ingo