From owner-freebsd-current Sat Jul 19 21:25:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA27909 for current-outgoing; Sat, 19 Jul 1997 21:25:49 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA27872; Sat, 19 Jul 1997 21:24:51 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id WAA28515; Sat, 19 Jul 1997 22:24:28 -0600 (MDT) Message-Id: <199707200424.WAA28515@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Bruce Evans cc: current@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: INT priorities In-reply-to: Your message of "Sun, 20 Jul 1997 14:03:37 +1000." <199707200403.OAA23396@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 22:24:28 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce, > The (non-SMP) kernel doesn't really care. It uses spl priorities > for essentially everything except fast interrupt handlers. For fast > interrupt handlers, the priorities only matter for interrupts that > arrive concurrently. I guess I should give a little background: The APIC provides 16 different priority levels for handling INTs. Because they are handled as messages, and each level has a 2 deep fifo, ideally we want at most 2 INTs assigned per level to avoid "message bounce". Because the timer and possibly other INTs can occur on non-standard IRQ #s, we can't compile in values for them. They can only be determined at run time. Another factor is that the APIC doesn't have 1 mask register like the 8259. Instead its an individual bit in a per-source register set, ie the 24 possible INTs sources are masked across 24 different registers. So keeping a bitmask in imen, and the bitmasks in the isa dev struct is of little use. Its actually counter-productive as many operations require a search of the mask for the particular bit of interest. It would be much better to keep INTs organized as logical INT #s, and use the # as an index into various tables, registers, etc. Given the need to reorganize INTs for the above reasons we might as well put a little thought into what goes where. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD