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

[Gabriel Paubert]

On Wed, Oct 05, 2011 at 05:31:48PM +0200, Thomas Gleixner wrote:
> 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/

Thanks.

> 
> > (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.


Well, for now I have my own registration, because when I originally wrote
the code (over a decade ago), there was no simple way to add potentially
~1800 additional interrupt sources (and the size of the interrupt descriptor
array on a machine with 16MB of RAM was not negligible, it became several
percent of the, minimalistic, kernel). 

This might be feasible now, but I still have boards with the first release 
of the bridge, which has very nasty interrupt related bugs (sometimes it 
incorrectly reports the level, only the vector is correct).

	Regards,	
	Gabriel