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
M. Warner Losh
imp at bsdimp.com
Tue Feb 8 21:07:08 GMT 2005
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.
More information about the cvs-src