From owner-freebsd-smp Sat Mar 9 20:48:30 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 746D737B405 for ; Sat, 9 Mar 2002 20:48:24 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g282BAt01489; Thu, 7 Mar 2002 18:11:10 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203080211.g282BAt01489@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: smp@FreeBSD.org Subject: Interrupt Context becomes a misnomer (was Re: Core recognizes SMPng tech lead ) In-reply-to: Your message of "Thu, 07 Mar 2002 18:56:17 MST." <20020307.185617.118790071.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 18:11:08 -0800 From: Michael Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org (moved to smp@) > This can be described as "newbus doesn't change often enough to do > anything other than one big lock around it." However, I must admit > that I've not thought through the implications of devices arriving and > leaving at interrupt context. I've been talking about this with various people, but here's a good point at which to bring up something that folks working on device drivers should think long and hard about. We should stop doing (almost) anything in "interrupt context". An interrupt handler should at most: - pacify the interrupting device - make the driver's interrupt thread runnable Now, before you all start screaming about "fast interrupts", yes, there are a few devices that require special treatment. But there aren't many of them, and they can be accomodated in this model (by doing slightly more in the interrupt handler). In the case where a device can't be "pacified" without considerable work (this is fairly rare), the handler can return status indicating that the interrupt should be masked until the thread has run. You can turn the concept on it's head and view it as making every driver have a "fast" interrupt handler. "Slow" handlers go away, making the issue of handling things "in interrupt context" much less of a problem, since almost nothing (clock code notwithstanding) is called from interrupt context. This isn't a particularly novel approach; Apple use it, BSD/OS is likely to go this way, and it's strongly encouraged by the IA64 interrupt model. I'm sure that plenty of other systems do things this way as well; I just don't have the research hours to track them down. Just food for thought at this stage, but something that anyone working on interrupt handling should take to heart. Regards, Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message