[lkml]   [2004]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: calling kthread_create() from interrupt thread
On Wed, 2004-06-16 at 05:01, Robin Holt wrote:
> We receive an interrupt. The interrupt handler determines that some work
> needs to be done. Part of that work to be done may result in the process
> needing to go to sleep waiting for a resource to become available.
> Currently, the interrupt handler wakes a thread sleeping on a
> wait_event_interruptible(). This wakeup is taking approx 35uSec. Dean
> is looking for a lower latency means of doing the wakeup.

The best approach is, as suggested in this thread, to have a fastpath
which is called from interrupt handler, which fails if it needs to
sleep; in that case you back off to your own workqueue. It'd look
something like:

static DEFINE_PER_CPU(struct work_struct slow_work);
static workqueue_struct *wq;

irqreturn_t do_interrupt(...)
if (!fast_irq_handle())
queue_work(wq, &__get_cpu_var(slow_work));

static void do_slow_work(void *unused)

static int __init init(void)
int cpu;
wq = create_workqueue("drivername", 0);
PREPARE_WORK(&per_cpu(slow_work, cpu),
do_slow_work, NULL);

You need to come up with a mechanism to pass details from the interrupt
handler to the do_slow_work() fn, probably a separate queue or array
which do_slow_work() will need to disable irqs to access. queue_work
will not requeue the work_struct if it's already pending, your
do_slow_work() needs to handle all the requests which are waiting.

Hope that helps,
Anyone who quotes me in their signature is an idiot -- Rusty Russell

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.045 / U:3.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site