From: "George Spelvin" <linux@horizon.com>
To: johnstul@us.ibm.com, mingo@elte.hu
Cc: linux-kernel@vger.kernel.org, linux@horizon.com,
tglx@linutronix.de, torvalds@linux-foundation.org,
ulrich.windl@rz.uni-regensburg.de, williams@redhat.com,
zippel@linux-m68k.org
Subject: Re: [RFC][PATCH] tsc_khz= boot option to avoid TSC calibration variance
Date: 8 May 2009 11:12:48 -0400 [thread overview]
Message-ID: <20090508151248.6888.qmail@science.horizon.com> (raw)
In-Reply-To: <20090508121521.GC18758@elte.hu>
> 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.
next prev parent reply other threads:[~2009-05-08 15:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-08 0:30 john stultz
2009-05-08 12:15 ` Ingo Molnar
2009-05-08 15:12 ` George Spelvin [this message]
2009-05-08 19:06 ` [RFC][PATCH] tsc_khz= boot option to avoid TSC calibrationvariance john stultz
2009-05-08 12:19 ` [RFC][PATCH] tsc_khz= boot option to avoid TSC calibration variance George Spelvin
2009-05-08 15:27 ` George Spelvin
2009-05-08 19:02 ` john stultz
2009-05-11 6:54 ` 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=20090508151248.6888.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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
all inboxes | Powered by JetHome®