Re: Unusually long delay in the kernel

From: Andrew Morton
Date: Sat Sep 17 2005 - 01:58:42 EST


Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/