Re: [patch 0/2] Run interrupt handlers always with interrupts disabled

[Jamie Lokier <jamie@shareable.org>]

Peter Zijlstra wrote:
> On Fri, 2010-03-26 at 10:20 +0100, Ingo Molnar wrote:
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > On Fri, Mar 26, 2010 at 12:06:44AM -0000, Thomas Gleixner wrote:
> > > > The following patch series removes the IRQF_DISABLED functionality
> > > > from the core interrupt code and runs all interrupt handlers with
> > > > interrupts disabled.
> > > 
> > > As was covered in previous discussions, what about drivers such as SMC91x 
> > > which take a long time to retrieve packets from the hardware? Always running 
> > > handlers with IRQs disabled will kill things such as serial on these 
> > > platforms.
> > 
> > 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.
> 
> Or alternatively, use threaded interrupts for such slow hardware.

What is the latency of threaded interrupts these days, compared with
non-threaded interrupts?

Slow hardware is quite sensitive to increases in latency.  Obviously
not a problem for the sources of latency: it's a problem for the irq
which is _sensitive_ to latency caused by the other one.  That is
typically a serial port or something.

But the benefit of kernel-settable interrupt priorities (i.e. due to
the threads) may be worth it even for serial ports.  I would love to
see some measurements comparing with and without.

-- Jamie