Re: Interrupt statistics?

On Sat, 11 Oct 2003, Nate Lawson wrote:

> Does anyone have recent statistics for interrupt latency and arrival
> timings?  I am very interested in our idle load characteristics.  It seems

According to machdep.siots, fast interrupt handler latency on an old
Celeron266 is about 10 usec (max) for short runs under favourable
circumstances (idle system and no hoggish fast interrupt handlers).

General interrupt latency can be huge (many msec), since some interrupt
handlers are blocked by Giant and Giant can be held for a long time.

> most systems I've analyzed have an average idle interrupt rate of about
> 225 per second, dominated by the clk and rtc interrupts as shown below.
>
> clk irq0            99/sec
> rtc irq8           127/sec
>
> Since these are both clocks, I assume the arrival of their interrupts are
> equally spaced and not correlated to each other.  How much latency do the
> handlers for these have?

About 10 usec (max), as above, since they are fast interrupt handlers
(except in my version).  In fact they are the main source of interrupt
latency (for other interrupts) on idle systems.

> Are there any system processes which generate
> repetitive bursts of very short tasks?  If so, how long do those tasks
> take?

I haven't noticed any significant sources of such (I don't use any
nonstandard hardware or sound cards).  Every system that I've looked at
(mainly my own and freebsd.org ones) has amazingly low interrupt activity,
with more rtc+clk interrupts than all others combined (except transiently).

> The reason why I ask is I'm coming up with a default policy for CPU sleep
> states which can have as high a latency as a few hundred microseconds.  On
> an idle system, this should be fine although it does add to the latency
> for the above clock handlers.  But I also need to be able to demote
> quickly to short sleep states (e.g., HLT) if the system is becoming active
> to decrease response times.

At least on i386's, the latency for clock interrupts is unimportant (except
possibly when kern.timecounter.hardware = i8254) since interrupts are not
used directly for timekeeping.

Bruce