Date: Sun, 11 Jan 2004 23:52:04 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Scott Long <scottl@freebsd.org> Cc: arch@freebsd.org Subject: Re: Interrupt API change Message-ID: <20040111234854.L36463-100000@mail.chesapeake.net> In-Reply-To: <4000CD54.30801@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040111234854.L36463-100000>