[patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD

[Thomas Gleixner]

On Wed, 5 Oct 2011, Gabriel Paubert wrote:

> On Wed, Oct 05, 2011 at 12:30:49PM -0000, Thomas Gleixner wrote:
> > The following series marks the obvious interrupts IRQF_NO_THREAD to
> > prevent forced interrupt threading - no guarantee of completeness :)
> > 
> > The last patch enables the forced threading mechanism in the core
> > code, which in turn enables the "irqthreaded" commandline option.
> 
> Is there any description of what "interrupt threading" means?

That means that the interrupt handler is running in a thread. The
interrupt itself merily wakes the thread. That's a debugging option in
mainline - it comes handy when interrupt handlers crash as the system
just kills the thread, but stays otherwise alive. If the same
situation happens in the normal hard interrupt context, then it takes
them machine down completely.

Aside of that it's a prerequisite to support PREEMPT_RT on your
arch/machine.

> I'm only looking for a pointer to a web page, a mailing list thread

https://lwn.net/Articles/429690/

> (I am no more subscribed to lkml, too many things to do, so maybe
> it has been discussed but it comes out of the blue on linuxppc-dev), 
> or a well commented git commit?
> 
> >From followups, I see that cascaded interrupt controller should
> not be threaded. I suspect that the private VME bridge driver
> (Universe chip) I maintain here will need it: clients request
> a given VME interrupt (level/vector) and specify an interrupt
> handler which is called by the handler for the PCI interrupt.

Can't tell as I don't know how your code looks like. If your
subinterrupts are registered with the core interrupt system and the
drivers install their handlers via request_irq(), then yes. If you
just have your own registration and handling stuff (which you
shouldn't) then you might be better off to let the dispatch interrupt
handler be threaded so that all the demuxed ones run in that same
thread.

Thanks,

	tglx