From: john stultz <johnstul@us.ibm.com>
To: George Spelvin <linux@horizon.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: ulrich.windl@rz.uni-regensburg.de, linux-kernel@vger.kernel.org,
tglx@linutronix.de, Clark Williams <williams@redhat.com>,
zippel@linux-m68k.org, Ingo Molnar <mingo@elte.hu>
Subject: [PATCH] tsc_khz= boot option to avoid TSC calibration variance
Date: Mon, 11 May 2009 19:12:01 -0700 [thread overview]
Message-ID: <1242094321.7214.156.camel@localhost.localdomain> (raw)
All,
Despite recent tweaking, TSC calibration variance is still biting users
who care about keeping close sync with NTP servers over reboots.
Here's a recent example:
http://lkml.indiana.edu/hypermail/linux/kernel/0905.0/02061.html
The problem is, each reboot, we have to calibrate the TSC, and any
error, regardless of how small, in the calibrated freq has to be
corrected for by NTP. Assuming the error is within 500ppm NTP can
correct this, but until it finds the proper correction value for the new
TSC freq, users may see time offsets from the NTP server.
In my experience, its fairly easy to see 100khz variance from reboot to
reboot with 2.6.30-rc.
While I think its worth trying to improve the calibration further, there
will likely be a trade-off between very accurate calibration and fast
boot times.
To mitigate this, I wanted to provide a tsc_khz= boot option. This would
allow users to set the tsc_khz value at boot-up, assuming they are
within 1Mhz of the calibrated value (to protect against bad values).
Once the tsc_khz value is set in grub, the box will always boot with the
same value, so the NTP drift value prior to reboot will still be correct
after rebooting.
Thanks to George Spelvin for the idea:
http://lkml.indiana.edu/hypermail/linux/kernel/0905.0/02807.html
Also thanks to George Spelvin for noticing and fixing the bogus
frequency comparison check in my original RFC'ed patch. This version of
the patch includes his much better comparison.
Signed-off-by: John Stultz <johnstul@us.ibm.com>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index e87bdbf..4c5d6aa 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2402,6 +2402,13 @@ and is between 256 and 4096 characters. It is defined in the file
Used to enable high-resolution timer mode on older
hardware, and in virtualized environment.
+ tsc_khz= [x86] Set the TSC freq value.
+ Format: <khz>
+ Used to avoid TSC calibration error.
+ The specified tsc_khz value must be accurate to the
+ calibrated tsc value by 0.1%. Otherwise the calibrated
+ value will be used.
+
turbografx.map[2|3]= [HW,JOY]
TurboGraFX parallel port interface
Format:
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index d57de05..d47c871 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -825,15 +825,40 @@ static void __init init_tsc_clocksource(void)
clocksource_register(&clocksource_tsc);
}
+unsigned long tsc_khz_specified;
+static int __init tsc_khz_specified_setup(char *str)
+{
+ tsc_khz_specified = simple_strtoul(str, NULL, 0);
+ return 1;
+}
+
+__setup("tsc_khz=", tsc_khz_specified_setup);
+
+
void __init tsc_init(void)
{
u64 lpj;
int cpu;
+ long difference;
if (!cpu_has_tsc)
return;
tsc_khz = calibrate_tsc();
+
+ /*
+ * If the calibrated TSC freq and user specified
+ * TSC freq are close enough, pick the what the
+ * user told us.
+ */
+ difference = abs(tsc_khz - tsc_khz_specified);
+ if (difference <= tsc_khz >> 10) { /* 1/1024 = 976 ppm */
+ printk(KERN_INFO "Using user defined TSC freq: %lu.%03lu MHz\n",
+ tsc_khz_specified/1000,
+ tsc_khz_specified%1000);
+ tsc_khz = tsc_khz_specified;
+ }
+
cpu_khz = tsc_khz;
if (!tsc_khz) {
next reply other threads:[~2009-05-12 2:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 2:12 john stultz [this message]
2009-05-12 8:36 ` [PATCH] tsc_khz= boot option to avoid TSC calibration variance Ulrich Windl
2009-05-12 22:26 ` john stultz
2009-05-12 22:42 ` Thomas Gleixner
2009-05-12 23:02 ` john stultz
2009-05-13 9:41 ` Petri Kaukasoina
2009-05-13 7:59 ` Ulrich Windl
2009-05-13 9:23 ` Petri Kaukasoina
2009-05-13 10:06 ` Petri Kaukasoina
2009-05-12 13:20 ` Serge Belyshev
2009-05-12 23:31 ` john stultz
2009-05-13 18:45 ` George Spelvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1242094321.7214.156.camel@localhost.localdomain \
--to=johnstul@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=ulrich.windl@rz.uni-regensburg.de \
--cc=williams@redhat.com \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox