Messages in this thread | | | Date | Fri, 3 Sep 1999 11:38:04 -0700 | From | David Schleef <> | Subject | Re: Shared interrupt (lack of) handling |
| |
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/
| |