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

Jamie Lokier
2010-03-26T12:02:51Z

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