Re: [PATCH] x86: Export tsc related information in sysfs

[Brian Bloniarz <bmb@athenacr.com>]

Ingo Molnar wrote:
> The point is for the kernel to not be complicit in 
> practices that are technically not reliable.

One usecase that hasn't been discussed is when userspace needs this info to
calibrate the TSC.

Take NTP as an example. It does a pretty good job of observing the drift in
gettimeofday() against a reference clock and correcting for it. This seems
to work well even when GTOD uses the TSC. But, it assumes that the drift
changes slowly.

That goes out the window on reboot, because the kernel only spends 25ms on
TSC<->PIT calibration and the value of tsc_khz can vary a lot from boot to
boot. Then NTP starts up and reads a drift value from /var/lib/ntp/ntp.drift
that it *thinks* is accurate. In our experience, it'll then spend up to 48
hours doing god knows what to the clock until it converges on the real
drift at the new tsc_khz.  initscripts could correct for the kernel's
recalibration, but tsc_khz isn't exported.

So it's too bad that it can't be exported somehow. The TSC on our
machines has proven to be stable for all intents and purposes; I just
checked 25 of my machines, most have uptime of >200 days, all of them
still have current_clocksource=tsc. After NTP or PTPd has been running
for a while, things converge, but being unable to reboot is a headache.
Using the HPET for gettimeofday() would be impractical for performance
reasons.