From owner-freebsd-arch@FreeBSD.ORG Wed Feb 28 20:17:30 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 2C9FA16A400 for ; Wed, 28 Feb 2007 20:17:30 +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 ECBA313C491 for ; Wed, 28 Feb 2007 20:17:27 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 21206 invoked from network); 28 Feb 2007 19:26:11 -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; 28 Feb 2007 19:26:11 -0000 Message-ID: <45E5D760.4030409@root.org> Date: Wed, 28 Feb 2007 11:26:24 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Poul-Henning Kamp References: <42793.1172652152@critter.freebsd.dk> In-Reply-To: <42793.1172652152@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: Wed, 28 Feb 2007 20:17:30 -0000 Poul-Henning Kamp wrote: > In message <45E4ADCD.4090909@root.org>, Nate Lawson writes: > >> Attached is a patch that uses eventhandlers to update the TSC freq. > > Question: are we at a point where the TSC-frequency reported by ACPI > is more precise than our own ad-hoc calibrations ? It's a valid question, but mostly irrelevant. This code only comes into play after the TSC freq has been changed by a cpufreq driver. If the freq never changes, we always use the original boot-calibrated value. For example, if the freq went from 1600 to 800 mhz, the original value is off by 100% with the current code. The values supplied by the cpufreq driver are definitely going to be a lot closer. In the long term, I have some calibration code that bde@ helped with that gets a very accurate value but may take a while to reach equilibrium (since it runs with interrupts enabled). This would only run once in a task thread the first time a given freq is chosen. Then we'd cache that value for that setting. -- Nate