[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091130203933.GC5560@shareable.org>
Date: Mon, 30 Nov 2009 20:39:33 +0000
From: Jamie Lokier <jamie@...reable.org>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
David Brownell <dbrownell@...rs.sourceforge.net>,
Eric Miao <eric.y.miao@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
John Stultz <johnstul@...ibm.com>,
Rusty Russell <rusty@...tcorp.com.au>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Nicolas Pitre <nico@...vell.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] warn about shared irqs requesting IRQF_DISABLED registered with setup_irq
Russell King - ARM Linux wrote:
> On Sun, Nov 29, 2009 at 03:18:40PM +0000, Jamie Lokier wrote:
> > Or we could do away with this silliness and just switch everything to
> > threaded interrupts with RT-priorities ;-)
>
> ... thereby needlessly increasing the latency of all interrupt handling
> and probably breaking some devices.
It's not that cut and dried. RT gives you priorities where you might
not have had them before, so in some cases can reduce worst-case
latency for critical devices. IRQF_DISABLED is a cheap two-level
priority scheme; RT threaded interrupts extend it.
The extra processing increases latency, yes, but that is in a sense a
scheduling fast-path problem; it's not _intrinsic_ to threaded
interrupts that they have to have higher latency (you don't have to
use the normal calculation or task switch to get equivalent
behaviour), but undoubtedly trying to optimise that leads to very
twisty code and state representations, and I don't see it happening in
Linux any time soon.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists