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..
> 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
- 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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message