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

[John Baldwin]

On Tuesday 08 February 2005 04:07 pm, M. Warner Losh wrote:
> In message: <200502081550.55445.jhb at FreeBSD.org>
>
>             John Baldwin <jhb at FreeBSD.org> 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 <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org