Re: Interrupt handling

Hi Andy

Andy Valencia wrote:
>
> [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.

I think I must be being particularly slow at the moment because I can't
really see why this should be the case - each UART had it's own
interrupt line, just logically OR'd to all of the others. Under the
circumstances that wouldn't appear to be any different to 8 completely
different types of device all hanging from the same interrupt line?

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

OK - point taken (I don't think I've really ever worried about more than
20k interrupts per second to date) We don't have this with VSTa of
course - or have you got VSTa/RT waiting for release? :-)

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

Hmm - I must admit that this is the same sort of approach I've taken
with the 8-bit stuff, but then again I've not been trying to do
everything with messages (I'm using shared memory and condition
variables so that I can sleep on one or more event, or wake all of my
sleepers up together).

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

I assume that under these circumstances the interrupt units that handle
these events must keep track of the number of events or queue them in a
stack (unlike the PC's ISA PIC) - otherwise there must be some really
nasty race conditions waiting to happen :-/

BTW as something of an aside - have you thought about implementing
support for VNC (either as a client or service). I just have a
suspicion that it would be quite nice to run VSTa as an xterm into a
Unix system or take over Windows PCs. Another thought is that it would
make it easier to use and develop VSTa for anyone who doesn't have space
for two sets of monitors, keyboards and mice.

                        Regards,
                        Dave
Received on Mon May 29 10:26:34 2000