Re: Unusually long delay in the kernel

[Fawad Lateef <fawadlateef@gmail.com>]

On 9/16/05, 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?
> 
> (2) Are the {un}lock_kernel calls really needed?
> 

AFAIR the article on the lwn.net in the driver porting porting to 2.6
kernel mentioned that big kernel locks lock_kernel and unlock_kernel
gone, but as I searched into the kernel's drivers directory for the
kernel_thread functions (drivers creating threads), I found some of
them using lock_kernel and some not .... So I also wants to know are
they really needed ??

By the way I havn't saw/felt any long delay when starting thread in
this way using lock_kernel !!!!


-- 
Fawad Lateef
-
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/