Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Feb 2007 22:19:53 -0800
From:      Nate Lawson <nate@root.org>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        arch@freebsd.org, current@freebsd.org
Subject:   Re: PATCH - update TSC freq when cpufreq changes it
Message-ID:  <45E67089.7070306@root.org>
In-Reply-To: <70793.1172694201@critter.freebsd.dk>
References:  <70793.1172694201@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <45E5D760.4030409@root.org>, Nate Lawson writes:
>> Poul-Henning Kamp wrote:
> 
>> It's a valid question, but mostly irrelevant.
> 
> Not at all.  It may be a lot cheaper for us to just use the
> value from the ACPI than to calibrate.  Only in the increasingly
> rare case where TSC is used for timecounter AND the system isn't
> using NTP is the precise frequency really interesting.
> 

Ah, that's something different.  I don't think it's a good idea to use
the provided value outright when something more empirical is available.
  With cpufreq modes like p4tcc or acpi_throttling, you only have a
relative setting anyway (i.e. 50%) so you still have to measure the base
freq at some point.  Boot is a good place to do it.

Ultimately, my goal is to re-calibrate (with intr on) each level the
first time it's used, then cache it in cpufreq as the "real" freq.  It
will provide that value in the cf_level struct and then eventhandler
consumers can use that.  That value will be accurate and empirical.  For
now, the goal is to just get TSC matching reality a little better (say
+/- 1% instead of +100% or so).

-- 
Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E67089.7070306>