From owner-cvs-src@FreeBSD.ORG Tue Feb 8 22:56:08 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADBDD16A4CE for ; Tue, 8 Feb 2005 22:56:08 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E85FD43D45 for ; Tue, 8 Feb 2005 22:56:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 10038 invoked from network); 8 Feb 2005 22:56:07 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Feb 2005 22:56:07 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j18Mu20m097507; Tue, 8 Feb 2005 17:56:03 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: "M. Warner Losh" Date: Tue, 8 Feb 2005 17:52:35 -0500 User-Agent: KMail/1.6.2 References: <200502082025.j18KP72E069507@repoman.freebsd.org> <200502081550.55445.jhb@FreeBSD.org> <20050208.140749.52472160.imp@bsdimp.com> In-Reply-To: <20050208.140749.52472160.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502081752.35022.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 apic_vector.s local_apic.c mp_machdep.c src/sys/i386/include apicvar.h smp.h src/sys/i386/isa clock.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 22:56:08 -0000 On Tuesday 08 February 2005 04:07 pm, M. Warner Losh wrote: > In message: <200502081550.55445.jhb@FreeBSD.org> > > John Baldwin writes: > : On Tuesday 08 February 2005 03:25 pm, John Baldwin wrote: > : > jhb 2005-02-08 20:25:07 UTC > : > > : > FreeBSD src repository > : > > : > Modified files: > : > sys/i386/i386 apic_vector.s local_apic.c mp_machdep.c > : > sys/i386/include apicvar.h smp.h > : > sys/i386/isa clock.c > : > Log: > : > Use the local APIC timer to drive the various kernel clocks on SMP > : > machines rather than forwarding interrupts from the clock devices > : > around using IPIs: - Add an IDT vector that pushes a clock frame and > : > calls lapic_handle_timer(). > : > - Add functions to program the local APIC timer including setting the > : > divisor, and setting up the timer to either down a periodic > : > countdown or one-shot countdown. > : > - Add a lapic_setup_clock() function that the BSP calls from > : > cpu_init_clocks() to setup the local APIC timer if it is going to > : > be used. The setup uses a one-shot countdown to calibrate the timer. > : > We then program the timer on each CPU to fire at a frequency of hz * 3. > : > stathz is defined as freq / 23 (hz * 3 / 23), and profhz is defined as > : > freq / 2 (hz * 3 / 2). This gives the clocks relatively prime divisors > : > while keeping a low LCM for the frequency of the clock interrupts. > : > Thanks to Peter Jeremy for suggesting this approach. > : > - Remove the hardclock and statclock forwarding code including the > : > two associated IPIs. The bitmap IPI handler has now effectively > : > degenerated to just IPI_AST. > : > - When the local APIC timer is used we don't turn the RTC on at all, > : > but we still enable interrupts on the ISA timer 0 (i8254) for > : > timecounting purposes. > : > : One caveat at the moment is that if you use ACPI throttle states (not Cx, > : but the hw.acpi.cpu.throttle_* (or whatever it's called now in a post > : cpufreq world) that the timer might operate at a different frequency. > : Currently there isn't a mechanism for notifying the system when the bus > : (not CPU clock) frequency changes, but once there is this will have to > : hook into it. > > Relying on a frequency that can change will lead to really bad time > keeping, even if there were a notification mechanism. TSC should be > the only one that's impacted by changes to the clock speed. All the > other time keeping mechanisms are independent of CPU clock speed. Note that this is not for {bin,micro,nano}{up,}time(), but to drive {hard,soft,stat}clock(). There is a difference between the two things. Specifically, this is not a timecounter device. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org