[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080903212729.436da8d3@infradead.org>
Date: Wed, 3 Sep 2008 21:27:29 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alok Kataria <akataria@...are.com>,
Thomas Gleixner <tglx@...utronix.de>,
Larry Finger <Larry.Finger@...inger.net>,
LKML <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, Michael Buesch <mb@...sch.de>,
Dan Hecht <dhecht@...are.com>
Subject: Re: [PATCH] Fix TSC calibration issues
On Wed, 3 Sep 2008 21:20:23 -0700 (PDT)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> I do agree that we could aim for something like that. But even to get
> the rough estimate, we'd probably have to do the 5ms thing.
5msec isn't too big a deal; 250ms otoh ;-)
>
> > another option for calibrating the tsc rate is to read it from the
> > msr's/cpuid/aperf of what the hardware says it should be, and then
> > all we need is to verify it is that; that we could do over timer or
> > quickly. (of course that only works for systems with constant tsc)
>
> I don't think it's reliable even for systems with a constant TSC.
> Because the msr/cpuid thing isn't going to actualyl give the right
> frequency. It might be the frequency the thing is _rated_ at, but it
> will be off when people over- or under-clock the front-side bus etc.
for 99%+ of the systems it'll be extremely close. We do need to
validate it to detect the overclocking etc (and if the calibration says
"it smells funny" we can do the slow 250msec thing)
--
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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/
Powered by blists - more mailing lists