linux-kernel - Re: [PATCH] usb: Use a workqueue in usb_add

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Jan 2012 15:51:29 -0800
From:	Greg KH <gregkh@...e.de>
To:	Simon Glass <sjg@...omium.org>
Cc:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>, linux-usb@...r.kernel.org,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Subject: Re: [PATCH] usb: Use a workqueue in usb_add_hcd() to reduce boot time

On Thu, Jan 26, 2012 at 03:48:43PM -0800, Simon Glass wrote:
> Hi Greg,
> 
> On Tue, Jan 24, 2012 at 9:22 AM, Greg KH <gregkh@...e.de> wrote:
> > On Tue, Jan 24, 2012 at 05:57:11PM +0100, Sebastian Andrzej Siewior wrote:
> >> * Alan Stern | 2012-01-21 11:11:09 [-0500]:
> >>
> >> >Doing time-consuming things later won't make any difference.  That is,
> >> >suppose the boot sequence performs activities A and B, where A takes a
> >> >long time.  Doing A later, so that the boot sequence performs B and
> >> >then A, won't change the total time required.
> >>
> >> That is true. However if you show the gui _now_ and look for USB later
> >> then it feels faster and this is usually enough.
> >
> > Which has been done before, with great success (i.e. we did it for
> > Moblin boot times), so it shouldn't be that big of an issue.
> >
> > Which points out the question, exactly what is the issue here?  We have
> > "multithreaded" pci driver startup for a long time now, did that stop
> > working here?  If you use bootchart, does it show that the USB host
> > driver is stoping the machine from proceeding to the next stage in the
> > boot process?
> >
> > From my experience, I never saw the USB host controller get in the way
> > at all, it was always somethine else happening that caused problems
> > (i.e. video.)
> >
> > Simon, do you have boot charts anywhere showing this?
> 
> I did have initcall timing when I last looked at this. USB was holding
> up progress. Sorry for the delay - I hope to get back to this next
> week.

Are you building your USB host controllers into the kernel, or are they
modules?

What is sitting on the USB bus that is needed for the boot process to
continue on to init and then later?  Is the root disk on it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/