linux-kernel - Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Jun 2015 19:06:25 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Andi Kleen <ak@...ux.intel.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Len Brown <lenb@...nel.org>
Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in
 quick_pit_calibrate()


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

> On Wed, 3 Jun 2015, Linus Torvalds wrote:
> > On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar <mingo@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/