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

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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTinJ36UBMsVvTEoPnmAVS6np9Ja6heEtKA93r7tp@mail.gmail.com>
Date:	Fri, 21 May 2010 19:03:16 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Brian Bloniarz <bmb@...enacr.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Venkatesh Pallipadi <venki@...gle.com>, chris.mason@...cle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Export tsc related information in sysfs

On Thu, May 20, 2010 at 12:19 PM, Brian Bloniarz <bmb@...enacr.com> wrote:
> 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.

Yea, the relative instability of the tsc calibration at boot is an
issue for folks who want very very precise timekeeping immediately
after a reboot.

I proposed a solution to this awhile back via a boot option users
could use to specify the tsc_khz freq, so it would be consistent from
boot to boot. See: https://patchwork.kernel.org/patch/22492/

It didn't really go anywhere due to a lack of public interest.
However, if you're interested in playing with it, I can try to revive
the patch.

thanks
-john
--
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/