[PATCH] Use local APIC timer to drive kernel clocks

[John Baldwin]

I have a patch that uses the local APIC timer to drive the kernel clocks 
(hardclock, statclock, and profclock) instead of the ISA timer and RTC.  The 
advantage of this change is that SMP machines can stop using IPIs to bounce 
clock interrupts around all the time.  Currently the code will always use the 
local APIC timer if an APIC is being used, but it might be desirable to only 
use the timer if we have more than one CPU.  Some caveats and details:

- statclock and profclock are not evenly distributed as they are when driven
  by the RTC.  Specifically, since there is only one timer in the APIC, I had
  to drive all 3 clocks from the same timer.  The current code uses two
  different timers with profclock and statclock being driven by the same
  timer.  Emulating this behavior completely requires that I run the APIC
  timer at the least common multiple of the 3 clocks and drive each clock via
  a software divisor.  With the default hz's of 1000, 128, and 1024 (hz,
  stathz, and profhz), I ended up having to run the timer at 128000 interrupts
  per second.  That didn't seem to be a good tradeoff for hz + profhz (2024)
  IPIs per second.  Instead, I went with a simpler algorithm suggested by phk
  that lets me run the timer at hz and guarantees that statclock() will be
  called stathz times per second, just not evenly spaced.  The same is true
  for profhz and profclock() with the exception that since the timer only runs
  at hz, if hz  is less than profhz (which it is by default), profhz runs at
  hz instead of 1024.
- Right now I have intrcnt entries for each CPUs timer as well as virtual
  counters representing how often the different clocks run on the BSP.  This
  is so you can verify that the clocks are running at the correct rates in
  systat -vmstat.  I might remove these counters or I might leave them in if
  this is eventually committed.
- The IPI_BITMAP handler has now degenerated back into just IPI_AST, but I've
  still left all the bitmap stuff in for now.
- The clock interrupt doesn't share a vector with the IPI priority group, but
  instead steals the highest vector from the previous group.  This does mean
  there's one less interrupt available for devices and MSI, but we have plenty
  to spare at the moment anyway, and will soon have oodles to spare when we
  start allocating the APIC vectors on demand rather than statically.

Please test and let me know if there are any regressions.  Thanks.  Patch is 
at http://www.FreeBSD.org/~jhb/patches/lapic_timer.patch

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org