Messages in this thread | | | Date | Sun, 19 Sep 1999 21:14:40 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: kernel-hacking-HOWTO: An lk primer seeks feedback |
| |
On Sun, 19 Sep 1999, Werner Almesberger wrote:
> - 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/
| |