> 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.
You spoke about "an interrupt occurs and no handler having work to do to
be stated spurious", so _you_ were buggy.
(Btw, if you want the scenario, I can provide)
> 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..."
If you change your mind, or the subject in the middle of the discussion,
you just invalidate all previous assertions, and better to stop here. You
just missed the fact that a useless interrupt cannot be stated spurious in
PCI and that only heuristics may be used to detect such a problem. Most
errors in PCI are due to people just missing concerns of that kind.
> > > 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.
It is all these kinds of bogus optimizations that made people claim that
software got faster and led to everything being mostly slower and way
bloated, in my opinion.
Gérard.
-
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/