Re: Interrupt statistics?

In message: <20031011234314.P23991_at_root.org>
            Nate Lawson <nate_at_root.org> writes:
: Does anyone have recent statistics for interrupt latency and arrival
: timings?

In -stable I know that we service fast interrupts in < 10us on a
666MHz machine 99.2% of the time.  I don't know about non-fast
interrupts, but other results suggest that we'd do 99+% in less than
100us.  This is to the first instruction of the ISR.  The ISRs that
I've been running typically run for 2us (since they do 30 instructions
plus 2 ISA I/Os).

I've not made similar measurments for -current, but those numbers do
represent at least some level of 'goal' to shoot for.

: I am very interested in our idle load characteristics.  It seems
: 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?  Are there any system processes which generate
: repetitive bursts of very short tasks?  If so, how long do those tasks
: take?

These are clock interrupts.  One is used for timing the system (clk),
while the other is used for profiling the system.  They are
asynchronous to each other so that the profiling can profile more
effectively.  On my systems with higher HZ setting, the clk interrupts
will happen more often, obviously.

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

The important thig with the time keeping devices is not to loose
interrupts, since that's how we tick out time.  On non-idle systems,
there's issues with latency on the ticks, but on idle systems there
wouldn't be.  100us of latency would effecively limit HZ to 5000 or so
(I think that the Nyquist limit would apply, otherwise it is 10000).
Some time units have a wrap around that makes 100Hz impossible and
faster rates must be used.

If you are going into a CPU state that's low, it might make sense to
increase the tick time, but I'm sure phk would have things to say
about that and its wisdom (or lack there of).

Warner