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>