Message-Id: <20090323172814.548471871@linutronix.de>
Date:	Mon, 23 Mar 2009 18:23:04 -0000
From:	Thomas Gleixner <tglx@...utronix.de>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Arjan van de Veen <arjan@...radead.org>,
	Jon Masters <jonathan@...masters.org>,
	Sven Dietrich <sdietrich@...e.de>,
	David Brownell <david-b@...bell.net>
Subject: [patch 0/2] Add support for threaded interrupt handlers - V3

This patch series implements support for threaded irq handlers for the
generic IRQ layer.

Changes vs. V2:
	- review comments addressed
	- simplified design
	- synchronize_irq adapted to threaded handlers

Threaded interrupt handlers are not only interesting in the preempt-rt
context. Threaded interrupt handlers can help to address common
problems in the interrupt handling code:

 - move long running handlers out of the hard interrupt context

 - avoid complex hardirq -> tasklet/softirq interaction and locking
   problems by integration of this functionality into the threaded
   handler code

 - improved debugability of the kernel: faulty handlers do not take
   down the system.

 - allows prioritizing of the handlers which share an interrupt line

The implementation provides an opt-in mechanism to convert drivers to
the threaded interrupt handler model contrary to the preempt-rt patch
where the threaded handlers are enabled by a brute force switch. The
brute force switch is suboptimal as it does not change the interrupt
handler -> tasklet/softirq interaction problems, but was the only way
which was possible for the limited man power of the preempt-rt
developers.

Converting an interrupt to threaded makes only sense when the handler
code takes advantage of it by integrating tasklet/softirq
functionality and simplifying the locking.

When a driver wants to use threaded interrupt handlers it needs to
provide a separate thread function, which is called from the per
device thread created in irq_request_threaded(). The primary handler
still needs to be supplied. It checks whether the interrupt was
originated from the device or not.

In case it was originated from the device the primary handler must
disable the interrupt at the device level and return
IRQ_WAKE_THREAD. The generic interrupt handling core then sets the
IRQF_RUNTHREAD in the irqaction of the handler and wakes the
associated thread.

The irqaction is referenced in the threads task_struct. The reference
is used to prevent further referencing of the thread in the interrupt
code in the case of segfault to make sure that the system (minus the
now dead interrupt handler) survives and debug information can be
retrieved. In the best case the driver can be restarted, but dont
expect that as a given.

The code was tested with a converted USB EHCI driver. The EHCI shares
an interrupt line with another device and both the threaded and the
non threaded handlers coexist nicely. 

Further the AHCI driver for ICH chipsets was converted and
tested. Interestingly enough this conversion did not cause worse
benchmark results with iobench and fio compared to the non threaded
mainline handler.

I'm still looking into a clean solution for the threaded demultiplex
handler case which was brought up by Dave to allow both the handling
of the demultiplexed devices in the context of the demultiplexer
interrupt thread and the wakeup of separate handler threads. But this
is an orthogonal extension of the existing patch set and does not
change the general design.

The patches apply on 
    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/threaded

The irq/threaded branch contains the generic irq related changes which are
already queued for .30

Thanks,

	tglx

--
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