On Mon, Jul 30, 2007 at 10:45:19AM +0100, Maciej W. Rozycki wrote:

On Sat, 28 Jul 2007, Russell King wrote:

quoted

Essentially, any complex interrupt handler (such as an IDE interrupt
doing a multi-sector PIO transfer _in interrupt context_) can cause this
kind of starvation.  That's why Linux 1.x had bottom halves - so that
the time consuming work could be moved out of the interrupt handler,
thereby causing minimal the blockage of other interrupts.

Unfortunately, that kind of design has been long since forgotten.
Apparantly modern machines are fast enough that it doesn't have to be
worried about anymore...  Or are they?

 I would guess it is not that the machines are fast enough, but that this 
two-level processing makes things more complicated.  Enough that most 
people would not bother digging into it unless really forced.  Only 
occasional latency problems are probably not enough of a force.

It's a shame we don't have a way to measure IRQ latency - it would be
very useful to flag up problems.

I think the best we could do is to arrange for the timer interrupt to
complain if it's delayed by more than 1ms or so - but some architectures
already run their timers with IRQF_DISABLED as a work around some of
the latency issues.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: