Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Jan 2004 21:13:08 -0700
From:      Scott Long <scottl@freebsd.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        arch@freebsd.org
Subject:   Re: Interrupt API change
Message-ID:  <4000CD54.30801@freebsd.org>
In-Reply-To: <20040111005502.O22604@gamplex.bde.org>
References:  <3FFEFA18.1060805@freebsd.org> <20040111005502.O22604@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> 
> Bruce
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4000CD54.30801>