Alan Stern <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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]
| |
 |