Re: Interrupt handling

[Dave Hudson <dave@humbug.demon.co.uk> writes:]

>FWIW I know about the sharing problem having supported 8 16550-style
>UARTs on a single interrupt line with a fast 8051 last year :-/

But that's *homogeneous* sharing. Heterogeneous sharing is when it gets
hairy.

>Back to the point though... when interrupts are shared, the general
>solution must be something like disabling the interrupt channel on the
>ICU and then hitting all of device servers attached to the interrupt
>source with an interrupt message.

OK for homogeneous, not so OK for heterogeneous.

>Now arguably this solution adds some overhead for queuing the interrupt
>messages to the device servers, but then again this is already accepted
>to a large extent in the design anyway.

Not at all. A little front-end (i.e., in the machine ISR) demuxing can both
identify the interrupting device, mask it at that device, and set the
device's server process runnable. The savings in overhead as compared to
polling numerous server processes is immense.

Note that, coming freshly off Cisco, I'm used to environments where
relatively modest CPU's handle a million interrupts per second. So my
approach to scaling for interrupts tend to be a little extreme.

>Of course one very useful optimization under these circumstances would
>be some form of priority queueing of messages (e.g. possibly allowing
>the interrupt messages to be made more important than some others).

I looked into this, and I thought a lot about this based on our discussions
(so very long ago) about problems you were having with priority inversion in
the RS-232 server. But as you've probably noticed, I found that it's much
cleaner (and keeps the message path streamlined) to use more than one queue
rather than encode priority into the IPC.

>BTW I thought that the only edge triggered PC interrupts were on the ISA
>bus (and even then it generally seems to be the PIC that's doing the
>edge triggering - the 4 Ethernet cards I've looked at in the last 2
>weeks all hold the interrupt line high until the cause of the interrupt
>is either masked within the Ethernet chipset or is ack'd).

PCI also has it as a standard interrupt mode. Also, very high end buses all
do it this way, because as your bus scales up, it becomes more and more like
a very fast network. Split transactions become the norm, and having
interrupts look like events rather than conditions falls out pretty
naturally.

Andy Valencia
Received on Mon May 29 08:12:18 2000