Re: lockdep and threaded IRQs (was: ...)

[David Brownell <david-b@pacbell.net>]

On Monday 02 March 2009, Ingo Molnar wrote:
> 
> > > Since you care about them - could you please send patches on top 
> > > of the IRQ threading patches to add support for them?
> > 
> > I'll look at that, and try to prepare something on top
> > of the version of the threading patches that gets into
> > the -next tree.  I got the impression there was going
> > to be a v3 of those patches soonish...
> 
> Great! We'll sort out any conflicts so dont worry about that - 
> you can pick up v2 just fine and post patches.

One such patch is about to come, with different $SUBJECT
and trimmed CC list.

Note however that it's completely independent of Thomas'
patches.  It only affects the IRQ dispatch sub-problem;
other bits seem to be needed too.


> If you mean to push the chaining bits into the IRQ thread too, i 
> think the chaining bits actually should never be threaded. Is 
> there a good reason to do that? 

The chaining bits *MUST* be threaded.  The lack of that
support was a key issue with Thomas' patch.  The issue
being that access to the IRQ status registers, as needed
to dispatch the IRQ, is only possible in contexts that
can sleep.  That seems like a good reason.  :)


> It's not like they will really  
> be preemptible (preempting a chaining thread would mean the 
> whole demuxing chain is held up => bad).

See above.  The reason to thread this IRQ handling is
that it can't be done outside of threads ... there's
no other way to access registers via I2C (or SPI, etc).

Accordingly there's no way to avoid preemption ... but
since these IRQs aren't on performance-critical paths,
that's really no bother.