> - 5.2: you may want to discuss disable_irq, disable_irq_nosync, and
> enable_irq. On most (all?) architectures, they are reasonably
> inexpensive ways to block specific interrupts. (BTW, why don't we
> actually have some kind of interrupt blocking that doesn't go down
> to the interrupt controller hardware ? Is the PIC part considered
> to be cheap enough in all possible cases ?)
I don't see what you're getting at.. Are you suggesting some sort of
software masking? If you get an unmasked interrupt x, you'll be thrown
into an interrupt handler with all interrupts masked. If you exit the
handler without clearing it, you immediately get it again. Alternately, if
you fudge the flags on the stack, you now have all interrupts blocked,
still not what you want.
What might be possible is 'lazy masking' - whenever an interrupt comes in,
check the kernel's 'in use' mask. If someone has marked it in use (via
disable_irq), the handler only then goes to the PIC to do the masking.
Unmasking is also easy. First clear the bit in the mask, then check
whether the old mask got pushed out. If so, push the new mask out
immediately.
This is a win iff
p * (i + m) + c < m
where p is the probability of an interrupt occurring while its masked, i
is the interrupt overhead, c is the (likely negligible) time to check for
mask on every interrupt, and m is the time it to do the masking (and
unmasking) on the PIC. I expect m to be relatively large compared to i,
especially when SMP sync is required, but that's just a guess. I'd also
guess p is pretty darn small in most cases - if it isn't then we're
getting lots of back to back interrupts and not getting any userspace work
done. So this might have some potential..
It's actually slightly better than this because everytime you're forced to
mask, you do the whole mask (at least on a given controller), rather than
just masking the interrupt in question. This also reduces contention for
or eliminates the irq controller spinlock.
It might even be possible to allow the other driver on a shared interrupt
to continue to get interrupts with a scheme like this as long as an
interrupt didn't come in for the device that's blocked.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/