Re: calling kthread_create() from interrupt thread

[Rusty Russell <rusty@rustcorp.com.au>]

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);
		for_each_cpu(cpu)
			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,
Rusty.
-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell