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

From: "George Spelvin" <linux@horizon.com>
To: hpa@zytor.com, linux@horizon.com
Cc: adrian.hunter@intel.com, ak@linux.intel.com,
	linux-kernel@vger.kernel.org, luto@amacapital.net,
	tglx@linutronix.de, torvalds@linux-foundation.org
Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()
Date: 3 Jun 2015 15:07:19 -0400	[thread overview]
Message-ID: <20150603190719.20769.qmail@ns.horizon.com> (raw)
In-Reply-To: <556F4C10.7050005@zytor.com>

> Not guaranteed either, and I know for a fact there are platforms out
> there which synthesize the RTC clock.

Interesting!  And surprising.  Doesn't that take more battery power?

> Ah, I wasn't aware of the PF (not PE) bit.  That suddenly makes it a lot
> more interesting.  So polling for the PF bit suddenly makes sense, and
> is probably the single best option for calibration.

I had forgotten about it, too.  But adapting the current calibration
loop to it is trivial.  You lose the ability to detect drasitcally
delayed reads, but the current code barely uses that.

> Well, on x86 hopefully the entropy problem should soon be history...

And the installed base will be replaced when?  You may recall a discussion
in December 2012 to *not* drop 486 support because people were still
using embedded clones of it with modern kernels.