Re: calling kthread_create() from interrupt thread

[Robin Holt <holt@sgi.com>]

On Tue, Jun 15, 2004 at 02:15:34PM -0400, Richard B. Johnson wrote:
> On Tue, 15 Jun 2004, Dean Nelson wrote:
> 
> > On Tue, Jun 15, 2004 at 07:49:37PM +0200, Arjan van de Ven wrote:
> > > On Tue, 2004-06-15 at 19:42, Dean Nelson wrote:
> > > > I'm working on a driver that needs to create threads that can sleep/block
> > > > for an indefinite period of time.
> > > >
> > > >     . Can kthread_create() be called from an interrupt handler?
> > >
> > > no
> > >
> > > >
> > > >     . Is the cost of a kthread's creation/demise low enough so that one
> > > >       can, as often as needed, create a kthread that performs a simple
> > > >       function and exits?  Or is the cost too high for this?
> > >
> > > for that we have keventd in 2.4, work queues in 2.6
> >
> > As mentioned above, it is possible for this "simple" function to sleep/block
> > for an indefinite period of time. I was under the impression that one
> > couldn't block a work queue thread for an indefinite period of time. Am
> > I mistaken?
> >
> > Thanks,
> > Dean
> >
> 
> If you make a kernel thread, it can sleep forever if it wants, you
> can wake it up with wake_up_interruptible() from an interrupt after
> you have laid out the work you want it to do. That kernel thread
> has access to all your kernel data space, plus can spin-lock to
> prevent an interrupt from changing things in critical sections,
> etc.
> 
> It's the greatest thing since sliced bread.
> 

The problem Dean is trying to address is as follows:

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.

Thanks,
Robin