[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Interrupt API change
- Subject: Interrupt API change
- From: scottl at freebsd.org (Scott Long)
- Date: Sat Jan 10 20:15:07 2004
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
I understand, and that's why I haven't committed to doing it yet.
Visit your host, monkey.org