* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Fri, 2010-03-26 at 09:59 +0000, Alan Cox wrote: > > > As long as it's rare (which it is) i dont see a problem: you can enable > > > interrupts in the handler by using local_irq_enable(), like the IDE PIO > > > drivers do. That way it's documented a bit better as well, because it shows > > > the precise source of the latency, with a big comment explaining it, etc. > > > > I don't think it's as rare as you think particularly in embedded, and the > > moment you start explicitly using local_irq_enable() you've simply moved > > the underlying problem back and made it far harder to grep for. > > We've got local_irq_enable_in_hardirq() which should be used and can easily > be grep'ed for. > > But yes, I would much prefer to simply convert these known slow handlers to > threaded interrupts. Yeah, agreed. So there's multiple solutions: - On old hw with a driver that nobody is willing to convert to threaded IRQs: use the existing local_irq_enable_in_hardirq() API. This preserves the status quo. - On new hw with new drivers where there's such a level of IRQ parallelism that enabling IRQs in hardirqs is not an option, use threaded IRQ handlers. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
