Re: [PATCH] Use local APIC timer to drive kernel clocks

On Fri, 2005-Jan-14 15:46:31 -0500, John Baldwin wrote:
>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.

What is the cost of an IPI compared to a hardware interrupt?

>  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.

This would seem to negate the benefit of statclock.  If a process
synchronises to hardclock, and statclock is derived from hardclock
then the process will also be synchronised to statclock - and can
therefore (at least partially) circumvent the scheduler's attempts
to stop processes hogging the CPI.

AFAIK, the numbers 128 and 1024 are not magical to the scheduler, they
are just convenient values that can be generated by the RTC.  Rather
than running the APIC timer at hz, you might get better detection of
"rogue" processes by running the APIC timer at (say) 3000Hz with
hz=apichz/3, profhz = apichz/2 (1500Hz) and stathz=apichz/23 (~130Hz)
or 20 (120Hz).  If it's acceptable hardclock to have significant
jitter, you could further reduce synchronisation by using a fractional
divisor for hz (eg hz=apichz/2.5).

-- 
Peter Jeremy