Re: Unusually long delay in the kernel

From: Fawad Lateef (fawadlateef_at_gmail.com)
Date: 09/16/05

  • Next message: Jeff Dike: "[PATCH 1/1] UML - UML/i386 cmpxchg fix" 
    Date:	Fri, 16 Sep 2005 22:58:36 +0500
To: Alan Stern <stern@rowland.harvard.edu>

    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/
  • Next message: Jeff Dike: "[PATCH 1/1] UML - UML/i386 cmpxchg fix"