From owner-freebsd-arch@FreeBSD.ORG Sun Jan 11 20:52:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02AFB16A4CE; Sun, 11 Jan 2004 20:52:10 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ED5F43D2F; Sun, 11 Jan 2004 20:52:06 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id i0C4q4D14607; Sun, 11 Jan 2004 23:52:04 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 11 Jan 2004 23:52:04 -0500 (EST) From: Jeff Roberson To: Scott Long In-Reply-To: <4000CD54.30801@freebsd.org> Message-ID: <20040111234854.L36463-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Interrupt API change X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 04:52:10 -0000 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" >