Interrupt API change

[Jeff Roberson]

On Sat, 10 Jan 2004, Scott Long wrote:

> Bruce Evans wrote:
> >
> > That'a about all it can do.  In the shared irq case, there is no
> > alternative to calling all the handlers if one of the handlers did
> > something, since activity by one handler is unrelated to activity by
> > others (except as an optimization that only works in the edge triggered
> > case -- devices usually rarely interrupt concurrently so assuming that
> > thety never do is usually most efficient).  In the non-shared case,
> > individual handlers can better decide about interrupt storms in a
> > device-specific way.  The non-shared case will hopefully be almost all
> > cases when APIC support becomes standard on i386's.
> >
>
> This is way too overly optimistic.  Interrupt routing is still limited
> by things like the number of physical PCI INTx lines.  The APIC can't
> do anything about devices that share the same physical line.
>
> MSI will help this, but I suspect that MSI will only be supported on
> the higher-end PCI/PCI-X cards, at least until PCI-Express is adopted.
> I wouldn't expect the shared PCI INTx line problem to go away for
> at least another 5-7 years.
>
> There is no reason to duplicate interrupt storm heuristics in every
> single PCI driver.  For now, the change will be essentially a no-op.
> However, getting it in will allow us to experiment with it in the
> future with ease.  I'm not advocating that we break shared interrupt
> semantics and use this to short-circuit handlers.
>
> >
> > The first level interrupt handler should call (or schedule) other levels
> > as necessary (as in RELENG_4, but not using inefficient scheduling as in
> > -current).
>
> I understand, and that's why I haven't committed to doing it yet.

There are still significant optimizations to be done in interrupt
scheduling.  It seems to me that the filter idea is not a good one if we
can make ithread scheduling extremely cheap, which we can.  Ideally, it
should just be little more than a stack switch.  I'd rather see us put
effort into this than put effort into defeating the goal of a system which
we have not even finished implementing yet.

Cheers,
Jeff

>
> >
> > Bruce
> >
>
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>