Messages in this thread | | | Date | Sat, 17 Sep 2005 16:41:17 -0700 | From | Andrew Morton <> | Subject | Re: 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/
| |