Re: Why no interrupt priorities?

[Michael Frank]

On Fri, 27 Feb 2004 14:53:45 -0600, Jesse Pollard <jesse@xxxxxxxxxxxxxxxx> wrote:

> On Friday 27 February 2004 13:19, Michael Frank wrote:
> > On Fri, 27 Feb 2004 12:55:55 -0600, Matt Mackall <mpm@xxxxxxxxxxx> wrote:
> > > On Fri, Feb 27, 2004 at 09:44:44AM -0800, Grover, Andrew wrote:
> > >> > From: Helge Hafting [mailto:helgehaf@xxxxxxxxxxxxx]
> > >> >
> > >> > Grover, Andrew wrote:
> > >> > > Is the assumption that hardirq handlers are superfast also
> > >> >
> > >> > the reason
> > >> >
> > >> > > why Linux calls all handlers on a shared interrupt, even if
> > >> >
> > >> > the first
> > >> >
> > >> > > handler reports it was for its device?
> > >> >
> > >> > No, it is the other way around.  hardirq handlers have to be superfast
> > >> > because linux usually _have to_ call all the handlers of a shared irq.
> > >> >
> > >> > The fact that one device did indeed have an interrupt for us
> > >> > doesn't mean
> > >> > that the others didn't.  So all of them have to be checked to be safe.
> > >>
> > >> If a device later in the handler chain is also interrupting, then the
> > >> interrupt will immediately trigger again. The irq line will remain
> > >> asserted until nobody is asserting it.
> > >>
> > >> If the LAST guy in the chain is the one with the interrupt, then you
> > >> basically get today's ISR "call each handler" behavior, but it should be
> > >> possible to in some cases to get less time spent in do_IRQ.
> > >
> > > Let's imagine you have n sources simultaneously interrupting on a
> > > given descriptor. Check the first, it's happening, acknowledge it,
> > > exit, notice interrupt still asserted, check the first, nope, check
> > > the second, yep, exit, etc. By the time we've made it to the nth ISR,
> > > we've banged on the first one n times, the second n-1 times, etc. In
> > > other words, early chain termination has an O(n^2) worst case.
> >
> > With level triggered you can just walk the chain, exit at the end of the
> > first cycle and  should the IRQ still be asserted you just incur the
> > overhead of exit and reentry of the ISR.
> >
> > Even with edge, I would not check alwasy from the beginning of the chain...
>
> You should... after all that first entry in the chain has the highest priority

Please also consider that physcial IRQ's are in practice assigned "semi randomly".

In a way IRQ priorities in general purpose computing applications are irrelevant :)

Lets say you have a bunch of devices demand service, all have to be serviced but
is either not significant which gets done first or the practival IRQ priorities
are "less than optimal":

Keyboard	IRQ1		Well buffered
NIC1		IRQ10		Buffered
NIC2		IRQ10		Buffered
USB		IRQ11		Buffered
serial port	IRQ3		Small FIFO (assuming '550)
serial port	IRQ4			"-"

Here, serial ports would would be most critical, however the priorities of IRQ3
and IRQ4 are below priorities of IRQ10 and IRQ11...

IMO, the best practical approach is to keep efficiency by walking the chain only
once. If the chain is longer, it may be  worthwhile to check the IRQ and exit
walking the chain if it is inactive.

Priorities in chains would make sense only in specialized applications under
controlled circumstances wrt IRQ and linking devices into chain at the priority
desired.

Regards
Michael





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/