Re: Unusually long delay in the kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Alan Stern <[email protected]> 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

> 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.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux