From owner-freebsd-arch@FreeBSD.ORG Thu Mar 1 06:19:34 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA5F916A408 for ; Thu, 1 Mar 2007 06:19:34 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD5C13C4BF for ; Thu, 1 Mar 2007 06:19:34 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 75603 invoked from network); 1 Mar 2007 06:19:36 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 1 Mar 2007 06:19:36 -0000 Message-ID: <45E67089.7070306@root.org> Date: Wed, 28 Feb 2007 22:19:53 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Poul-Henning Kamp References: <70793.1172694201@critter.freebsd.dk> In-Reply-To: <70793.1172694201@critter.freebsd.dk> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, current@freebsd.org Subject: Re: PATCH - update TSC freq when cpufreq changes it X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2007 06:19:35 -0000 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