Messages in this thread | | | Date | Fri, 26 Mar 2010 11:53:58 +0100 | From | Ingo Molnar <> | Subject | Re: [patch 0/2] Run interrupt handlers always with interrupts disabled |
| |
* Peter Zijlstra <peterz@infradead.org> 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
| |