diff mbox

[2/2] arm: Allow forced irq threading

Message ID 20130214205304.993009840@linutronix.de (mailing list archive)
State New, archived
Headers show

Commit Message

Thomas Gleixner Feb. 14, 2013, 8:53 p.m. UTC
All timer interrupts and the perf interrupt are marked NO_THREAD, so
its safe to allow forced interrupt threading.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/arm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

Comments

Russell King - ARM Linux Feb. 14, 2013, 9:49 p.m. UTC | #1
On Thu, Feb 14, 2013 at 08:53:53PM -0000, Thomas Gleixner wrote:
> All timer interrupts and the perf interrupt are marked NO_THREAD, so
> its safe to allow forced interrupt threading.

What effect does this have on IRQ latency, particularly on the slower CPUs?

If it adds to the IRQ latency, then it must be conditional; there are
platforms where IRQ latency is important for things like network devices
to keep up (particularly the SMC NICs).
Thomas Gleixner Feb. 14, 2013, 10:04 p.m. UTC | #2
On Thu, 14 Feb 2013, Russell King - ARM Linux wrote:

> On Thu, Feb 14, 2013 at 08:53:53PM -0000, Thomas Gleixner wrote:
> > All timer interrupts and the perf interrupt are marked NO_THREAD, so
> > its safe to allow forced interrupt threading.
> 
> What effect does this have on IRQ latency, particularly on the slower CPUs?
> 
> If it adds to the IRQ latency, then it must be conditional; there are
> platforms where IRQ latency is important for things like network devices
> to keep up (particularly the SMC NICs).

It does not affect anything unless you add "threadirqs" to the kernel
command line. This command line argument puts the kernel into forced
irq threading mode. Otherwise it just works as now.

And yes, if enabled on the command line it adds latency due to the
delayed invocation of the handler in the thread.

Though for mainline this is primary a debug mechanism where you can
morph the kernel explosion in the interrupt handler into a takedown of
the handler thread instead of crashing the machine completely.
 
Now on RT we force this and I can tell you that even on slow machines
with SMC NICs the overhead seems to be in a range where these systems
can cope with. Of course, if you tweak the scheduling params of the
irq thread low enough you can run into problematic situations. But
that's not an ARM specific problem, that's a general problem of
configuring a RT system.

Thanks,

	tglx
diff mbox

Patch

Index: linux-2.6/arch/arm/Kconfig
===================================================================
--- linux-2.6.orig/arch/arm/Kconfig
+++ linux-2.6/arch/arm/Kconfig
@@ -17,6 +17,7 @@  config ARM
 	select GENERIC_STRNCPY_FROM_USER
 	select GENERIC_STRNLEN_USER
 	select HARDIRQS_SW_RESEND
+	select IRQ_FORCED_THREADING
 	select HAVE_AOUT
 	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
 	select HAVE_ARCH_KGDB