Date: Mon, 25 Feb 2002 19:58:33 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, John Baldwin <jhb@FreeBSD.ORG>, <dfr@nlsystems.com>, <current@FreeBSD.ORG> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assembly revamp, please review! Message-ID: <20020225191521.B40006-100000@gamplex.bde.org> In-Reply-To: <200202250137.g1P1bXq27219@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 24 Feb 2002, Matthew Dillon wrote: > ... > :If so, I'm wondering if this is even possible on alpha, where we don't > :have direct access to the hardware. However, according to the psuedo > :code for rti in the Brown book, munging with the saved PSL in > :trapframe to set the IPL should work. Hmm.. > : > :Drew > > Well, on IA32 there are effectively two types of interrupts (edge > and level triggered), and three interrupt masks (the processor > interrupt disable, a master bit mask, and then the per-device > masks), and two ways of handling interrupts (as a scheduled > interrupt thread or as a 'fast' interrupt). "master bit mask" seems to be an unusual name for the i386's ICU/or APIC (PIC or APIC in full i386-speak). > Note that the masking requirement is already part and parcel in > -current because most interrupts are now scheduled. The hardware > interrupt routine must schedule the interrupt thread and then > mask the interrupt since it is not dealing with it right then > and there and must be able to return to whatever was running before. > The interrupt thread will unmask the interrupt when it is through > processing it. Some more points related to this: - a mask outside of the CPU is required for SMP. - I believe interrupt masks and not levels are a fundamental requirement for proper scheduling as -current does it. A set of levels like the alpha's IPL doesn't work right because it doesn't permit masking individual interrupts (that have occurred) so that the kernel can keep running a thread whose priority is higher than that of the thread that will handle the interrupt, all according to the kernel's idea of priorities (which might differ significantly from the IPL's idea. There are also implementation problems. The IPL must be treated like an ICU and not restored reentrantly like IPLs usually are. - The worst case for priorities is when there is only a 2-state IPL, which is what an i386 without an ICU/APIC has. Then there can be only 2 really different kernel interrupt priorities (high and low), and the kernel ithread scheduling is just a waste of time. A 2- state IPL would obviously be bad for SMP, but for UP I often feel that it is the case that should be optimized -- this would force all critical regions and interrupt handlers to be short, which would be good for all cases. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020225191521.B40006-100000>