Re: Shared interrupt (lack of) handling

David Schleef (ds@stm.lbl.gov)
Fri, 3 Sep 1999 11:38:04 -0700

On Fri, Sep 03, 1999 at 08:32:43PM +0200, Gerard Roudier wrote:
> >
> > I appear to be missing something. What do PCI synchonization issues
> > have anything to do with a driver giving the OS hints? The delivery
> > of interrupts to the handlers would not change, but only that messages
> > *might* get printk'd if an interrupt occurs and no handler thinks that
> > the interrupt belongs to it. How often do spurious interrupts occur
> BTW, "share" is kind of opposite of "belong".
> > in a correctly functioning computer that shares interrupts between,
> > say, a NIC and SCSI card?
>
> An PCI interrupt that occurs and no device (sharing the INT line) having
> things to do may happen in PCI without being a spurious interrupt (even if
> this is probably a rare situation). Your statement let me think that your
> knowledge on PCI is just ISA+.

But this will only happen if there are synchonization "effects". It
should not occur in the average case (i.e., >10% of interrupts). If
it does, it indicates to me one of three things: a buggy board, a
buggy driver, or a buggy PCI standard.

I'd be somewhat bothered if I found out that my computer was handling
100+ interrupts per second in which the device said "Oops... I didn't
really mean that..."

>
> > One thing that you could do with the I_DID_SOME_STUFF flag is use the
> > statistics to reorder the execution of interrupt handlers so that the
> > device that causes the most interrupts gets called first. Might be
> > cool, difficult to tell.
>
> You _must_ call all interrupt handlers that requested the same IRQ when
> this IRQ is raised. So your flag does not optimize anything.

It optimizes latency, that is all.

dave...

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