Messages in this thread Patch in this message | | | Date | Sat, 18 Sep 1999 05:09:12 -0400 | From | Paul Gortmaker <> | Subject | [patch] SA_INTERRUPT information |
| |
I put this together from various posts I'd saved - others might as well benefit from the information too.
Paul.
--- /dev/null Mon Dec 31 23:00:00 1979 +++ linux-2.3.18ac5/Documentation/SA_INTERRUPT.txt Sat Sep 18 04:38:53 1999 @@ -0,0 +1,130 @@ +Info regarding SA_INTERRUPT cut from messages by Linus to linux-kernel: + + +Sun, 20 Sep 1998: +----------------- + +A small historical background on the issue.. + +SA_INTERRUPT _used_ to mean (a _long_ long time ago): + - incomplete stack frame, with only the non-preserved registers saved on + the frame. This meant, for example, that we couldn't handle signals etc + from a fast interrupt handler, because the stack wasn't set up for + signal handling. + - no PIC masking, and the PIC ACK done after the interrupt handler. This + was made possible by guaranteeing that interrupts would not be enabled + during SA_INTERRUPT processing, so we didn't need to mask out the + interrupt. + - no bottom half handling (well, this was originally even before bottom + halves existed) + +Essentially, the SA_INTERRUPT thing was meant to be a truly lightweight +interrupt handling system, where it took just a few cycles to get into the +real handler. It was most useful for serial interrupts that were extremely +timing-critical (they still are, but CPU speeds have made the overhead +less of an issue). + +These days, SA_INTERRUPT has none of the above meanings. For various +reasons, not the least of which is just my own sanity, the differences +between fast and "slow" interrupts have become less and less. + +First people wanted bottom half handling as a response to serial +interrupts, because it made a huge difference to PPP latency. That already +meant that some of the advantage of a bottom-half interrupt was no longer +there. Then, with the new SMP code, it just became clear that it made no +sense at all to have the difference, because the interrupt entry code +became fairly involved (I definitely didn't want to have two separate +copies). + +These days the _only_ difference that SA_INTERRUPT makes is that a handler +that has SA_INTERRUPT set will not enable local interrupts on the CPU it +is running. Or rather, the generic code won't enable the interrupts +automatically: the low-level drivers can still enable them if they want +to. + +That's a rather arbitrary difference, and not one worth maintaining, I +think. I should just remove that test. + + +Sat, 11 Jul 1998: +----------------- + +Don't bother with the "fast interrupt". It was never any faster than the +slow one. It had slightly different semantics wrt the return path, but the +original meaning of the fast interrupt was that it wouldn't play any games +with the interrupt controller, because it would never enable interrupts, +so there were no re-entrancy issues. Not playing any interrupt controller +games meant avoiding the overhead of several IO instructions, and that +would have been meaningful. + +That was in pre-1.0.x days - even fast interrupts were changed to mask the +interrupt controller because too many people wanted them. The only +difference between a fast and a slow interrupt was that the fast one +didn't do the bottom half handling, and didn't check for signals, and due +to that a lot of people actually complained about ppp latencies etc. + +What you _should_ do, and what the code is actually set up to support +already, is to instead of having the notion of "fast" vs "slow" (which was +completely broken), you should look into having the interrupt routines +return a value. The return path can then check whether it should do bottom +halves or not depending on that value. + +This is because a lot of the things that really want fast interrupts, +don't actually want the interrupts to be _always_ fast, they want them to +be fast most of the time. The static "SA_INTERRUPT" flag was too static. + +For example, if you have high-speed serial devices, they usually do not +want to do a bottom half for each interrupt. However, to avoid latency +problems with packets etc, they _do_ want to be able to say "ok, my +ping-pong buffer is getting full, please do a bottom half interrupt now", +or "ok, I got the end-of-packet marker, now it makes sense to get a whole +packet, so do the bottom half now". + +And THEN they want the bottom half handler to be done immediately. + +This is actually completely done already, if you look at irq.c. The only +part that is missing is the return value from the interrupt handlers, so +right now the code has something like + + if (1) { + if (bh_active & bh_mask) + do_bottom_half(); + } + +while it instead should look something like + + flags = irq_desc[irq].handler->handle(irq, cpu, ®s); + + if (flags & INTERRUPT_DO_BH) { + if (bh_active & bh_mask) + do_bottom_half(); + } + + if (flags & INTERRUPT_DO_SIGNALS) { + return through signal checking code + } + +but it would mean that every interrupt handler would have to return a +value (it might not be too painful to just make them all return 0, and +then one by one the ones that know about their needs could be changed). + +[...] + +> It would be generally useful to handle nested interrupt of different +> kinds (higher priority irq A interrupts irq B). + +We have always done that (since long before 1.0). The nesting is a +per-interrupt thing, and is only disallowed for the _same_ interrupt. + +Also note that if all interrupt handlers on a given IRQ line have the +SA_INTERRUPT flag set, then 2.1.x (and all earlier kernels for that +matter) don't allow any nesting at all, because the irq handler won't +enable interrupt locally. You can still get "nested" interrupts (of a +different type) on different CPU's, but they'll also have different +stacks. + +[...] nesting a timer interrupt (or something else) with another interrupt +has always been allowed, and still is. And that is still disallowed by +"fast" interrupts (it is in fact the only meaning that the SA_INTERRUPT +flag still has). +
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - 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/
| |