From: Gabriel Paubert <paubert@iram.es>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD
Date: Thu, 6 Oct 2011 13:06:45 +0200 [thread overview]
Message-ID: <20111006110645.GA18554@iram.es> (raw)
In-Reply-To: <alpine.LFD.2.02.1110051722140.18778@ionos>
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
prev parent reply other threads:[~2011-10-06 11:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 12:30 [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD Thomas Gleixner
2011-10-05 12:30 ` [patch 1/4] powerpc: 85xx: Mark cascade irq IRQF_NO_THREAD Thomas Gleixner
2011-10-05 12:30 ` [patch 2/4] powerpc: wsp: Mark opb cascade handler IRQF_NO_THREAD Thomas Gleixner
2011-10-05 12:30 ` [patch 3/4] powerpc: Mark IPI interrupts IRQF_NO_THREAD Thomas Gleixner
2011-10-05 12:30 ` [patch 4/4] powerpc: Allow irq threading Thomas Gleixner
2011-10-05 13:29 ` [patch 0/4] powerpc: Mark various interrupts IRQF_NO_THREAD Gabriel Paubert
2011-10-05 15:31 ` Thomas Gleixner
2011-10-06 11:06 ` Gabriel Paubert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111006110645.GA18554@iram.es \
--to=paubert@iram.es \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).