[PATCH] Statclock aliasing by LAPIC

[Attilio Rao]

Handling all the three clocks (hardclock, softclock, profclock) within
the LAPIC can lead to aliasing for the softclock and profclock because
hz is sized to fit mainly hardclock. The fashion to handle all of them
within the LAPIC was introduced in 2005 and before than the softclock
and profclock were supposed to be handled in the rtc. Right now, too,
there is the necessary support to handle profclock and statclock in
atrtc which gets enabled if the LAPIC signals it can't take in charge
the three clocks.
The proposed patch reverts the situation preferring the atrtc to
handle the statclock and profclock (then a different source from the
LAPIC) and then avoid the aliasing problem:
http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/statclock_aliasing3.diff

In this patch, lapic_setup_clock() has been changed in order to return
a three-states variable which identified if the LAPIC got in charge
all the three clocks, just the hardclock or none of them (the current
situation is just none/all) and the rtc handling runs subsequently.
A tunable as been added to force LAPI to get in charge all the three
clocks if needed.
In ia32 atrtc compiling is linked to atpic compiling, so a compile
time flag has been added to check if atpic is not present and in case
force LAPIC to take in charge all the three clocks (which is still
better than the 'safe belt values' still present in the rtc code).

Please note that statclock and profclock are widely used in our kernel
(rusage is, for example, statclock driven) and fixing this would
result in specific improvements (as a several-reported wrong CPU usage
statistic in top).
This bug has been found by Sandvine Incorporated.

Reviews, comments and testing are welcome.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein