Re: [RFC][PATCH] irq: remove IRQF_DISABLED

Linus Torvalds
2009-03-02T17:13:15Z

On Mon, 2 Mar 2009, Peter Zijlstra wrote:
>
> Would you be willing to take such a patch?

Yes - some day.

The "irq's disabled fastpath" thing has been there since pretty much day
one, because some irq handlers always wanted it. Making it the default
(and the only choice) is fine.

HOWEVER.

The fact is, some interrupt handlers are too slow for this. If you are
using a PIO IDE driver, not enabling interrupts will not only make you
lose serial line interrupts like mad (even at slow speeds), but has
historically resulted in even timer interrupts being lost because the IDE
layer is so slow.

The thing is, with PIO, a 512-byte disk read ends up doing 256 16-bit word
reads from the controller, each potentially up to 600ns long (PIO0
timings). That's 150ms - for a single sector!

Now, IDE controllers that we end up using PIO on all tend to be pretty
old, but admittedly even the old ones are faster than the worst-case
timings, so in practice you're not looking quite at that kind of horror
case, but you're still looking at each sector transfer (256 16-bit words)
taking on the order of tens of us.

For example, Mode2 timings are probably still something we should consider
realistic, and that's 240ns per word - a single sector now takes ~60ms to
read off the disk.

And we don't do single sectors. Most transfers will be 8 sectors (4k
contiguos read). So now that 60ms is 480ms per such IDE interrupt. And
even with the _good_ timings, we're certainly looking at a reduction of
that to about half.

Imagine what happens when we have interrupts disabled for half a second at
a time.

In other words, I do not think we are ready for this.

Now: I suspect you don't have a single machine that does PIO by default,
and you probably haven't had any for the last ten years. These things
_are_ old. But they do exist.

Could we make IRQF_DISABLED the default? Hell yes. We probably should. But
we realistically can't remove the non-disabled case, until you also have a
(tested) patch to fix these kinds of issues for the IDE PIO case (and
possibly others - IDE is the one I _know_ needs it).

Could we make just the IDE driver itself enable interrupts? Sure. But that
means that the interrupt controller code needs to know that some drivers
may enable interrupts and they may have recursive interrupts occurring. In
which case you really do want a flag anyway, since the interrupt
controller may well end up deciding that the "we're not going to enable
interrupts" case allows certain optimizations (like just ACK'ing it
immediately and not masking it at the interrupt controller).

So this is not as simple as your patch. Not even _nearly_.

Linus