linux-kernel - Re: [RFC][PATCH] tsc_khz= boot option to avoid TSC calibration variance

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:	8 May 2009 11:12:48 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	johnstul@...ibm.com, mingo@...e.hu
Cc:	linux-kernel@...r.kernel.org, linux@...izon.com,
	tglx@...utronix.de, torvalds@...ux-foundation.org,
	ulrich.windl@...uni-regensburg.de, williams@...hat.com,
	zippel@...ux-m68k.org
Subject: Re: [RFC][PATCH] tsc_khz= boot option to avoid TSC calibration variance

> Wouldnt it be a lot more flexible to have a sysctl for this, which 
> would be set before ntpd is started? (or which would be set by ntpd)

I thought so, but a boot-time option is sufficient and simpler.

> The mechanism and semantics would be similar: we would _not_ expose 
> cpu_khz directly, we'd have a boot_cpu_khz value saved for sure, and 
> we'd allow the sysctl to set the cpu_khz to within 1MHz of cpu_khz - 
> and we'd re-scale the timer irq and other calibrated values 
> accordingly.

Yes, that would be nicer.

> Alternatively, a much simpler method: why doesnt ntpd save its own 
> notion of cpu_khz once it has reached stability, and reads cpu_khz 
> (from /proc/cpuinfo) during bootup and re-scales its initial offset 
> and phase shift accordingly, compensating for that noise? (if it's 
> within 1MHz)

The problem is, it's only an issue if the TSC is used as the system
time base, which is a kernel detail that a) NTP really doesn't want to
be bothered with, and b) can change at run time.

It's possible, but it feels like a kludge.  It's such a Linux-specific
detail that it seems cleaner to fix it at the source.
--
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/