On Tue, 2007-03-06 at 22:44 -0800, Bill Irwin wrote: > At some point in the past, I wrote: > >> I'm certainly in favor of the move; IRQ stacks could be made > >> rather deep and cheaply at that. I may get around to writing it this > >> week if no one else does it first. > > On Tue, Mar 06, 2007 at 08:28:35PM -0800, Arjan van de Ven wrote: > > the irq stacks aren't the problem; RH at some point accidentally shipped > > a kernel with 4k *shared* irq/user context stack and even that gave > > almost no issues. > > irq's really shouldn't actually nest; it's bad for just about everything > > to do that (but that's another story, I would *love* to get rid of the > > "enable irqs" thing in the x86 irq path, it hurts just about anything in > > reality) > > What do you see as the obstacle to eliminating nested IRQ's?
political will, or maybe just the lack of convincing people so far > It doesn't > seem so far out to test for being on the interrupt stack and defer the > call to do_IRQ() until after the currently-running instance of do_IRQ() > has returned, or to move to per-irq stacks modulo special arrangements > for the per-cpu IRQ's. Or did you have other methods in mind? it's simpler... irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action) { irqreturn_t ret, retval = IRQ_NONE; unsigned int status = 0; handle_dynamic_tick(action); if (!(action->flags & IRQF_DISABLED)) local_irq_enable_in_hardirq(); just removing the if() and the explicit IRQ enabling already makes irqs no longer nest... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/