lkml.org 
[lkml]   [2005]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Unusually long delay in the kernel
Alan Stern <stern@rowland.harvard.edu> wrote:
>
> > Presumably it's spinning on the bkl. Is this actually an SMP machine? If
> > so, perhaps some other process is holding the bkl for a long time. Perhaps
> > a netdevice spending a long time diddling hardware in an ioctl, something
> > like that.
>
> I need to do more precise tests. Some quick informal tests indicated that
> the lock_kernel call and the daemonize call each took a noticeable time.

Something odd is happening.

> > That code could be converted to the kthread API btw.
>
> Hmph. Near as I can tell, the only changes that would involve are:
>
> Converting the thread creation call from kernel_thread to
> kthread_run.
>
> Adding another call to wake the thread up once it has been
> created.
>
> Removing the call to daemonize.
>
> There wouldn't be any need to call kthread_stop -- and in fact it wouldn't
> work, as the thread waits on a semaphore while it is idle (kthread_stop
> can't cope with things like that).

Well I was assuming that the semaphore would go away as well. Kernel
threads normally use waitqueues to await more work.

>
> That reminds me, I've got another question. Once a thread has called
> daemonize, or if it was started using kthread_run, all its signals are
> blocked. Is it still possible that through some extraordinary
> circumstance the thread could receive a signal, or are we absolutely
> guaranteed that no signals will arrive until the thread enables them?

Kernel threads should sleep in state TASK_INTERRUPTIBLE, with all signals
blocked. Because they don't want to contribute to the load average, and
because they shouldn't use signals.

So if it was possible to deliver a signal to an all-signals-blocked kernel
thread, that kernel thread would go into a busy loop, because all of its
sleep attempts will fall straight through (signal_pending() is true). So I
think it's safe to assume that nobody ever does force_sig() on a kenrel
thread.

> It's important to know the answer, because normally a thread spends its
> idle time waiting on down_interruptible or something similar. If a signal
> managed to get through somehow, the thread would never be able to go back
> to sleep unless it explicitly flushed its signals.

Yup.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-18 01:45    [W:0.067 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site