Re: Unusually long delay in the kernel

[Andrew Morton <akpm@osdl.org>]

Alan Stern <stern@rowland.harvard.edu> wrote:
>
> This code excerpt is taken from the start of the control thread for the 
>  usb-storage driver in 2.6.14-rc1:
> 
> 
>  static int usb_stor_control_thread(void * __us)
>  {
>  	struct us_data *us = (struct us_data *)__us;
>  	struct Scsi_Host *host = us_to_host(us);
> 
>  printk(KERN_INFO "Before thread start\n");
>  	lock_kernel();
> 
>  	/*
>  	 * This thread doesn't need any user-level access,
>  	 * so get rid of all our resources.
>  	 */
>  	daemonize("usb-storage");
>  	current->flags |= PF_NOFREEZE;
>  	unlock_kernel();
>  printk(KERN_INFO "After thread start\n");
> 
> 
>  The code between the two printk's takes a long time to run.  I don't have 
>  precise numbers, but it feels like more than 1 second.
> 
>  (1) Can anyone explain why, or indicate how to speed it up?

What's it doing at the time?  (kgdb is great for this sort of thing: hit
^C, go for a wander through the thread callchains).

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.

>  (2) Are the {un}lock_kernel calls really needed?

Definitely not.

That code could be converted to the kthread API btw.
-
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/