All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Simon Glass <sjg@chromium.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Alan Stern <stern@rowland.harvard.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	Sarah Sharp <sarah.a.sharp@linux.intel.com>
Subject: Re: [PATCH] usb: Use a workqueue in usb_add_hcd() to reduce boot time
Date: Thu, 26 Jan 2012 16:07:23 -0800	[thread overview]
Message-ID: <20120127000723.GB14678@suse.de> (raw)
In-Reply-To: <CAPnjgZ3=ddUTC231YFCqoDHFFGpn5EJAhXoLFgqwG9KJfTCf_g@mail.gmail.com>

On Thu, Jan 26, 2012 at 03:57:23PM -0800, Simon Glass wrote:
> Hi Greg,
> 
> On Thu, Jan 26, 2012 at 3:51 PM, Greg KH <gregkh@suse.de> wrote:
> > 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@suse.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?
> 
> A hub with a few things on it (Ethernet, USB stick). No we don't
> normally have a root disk on it - we could in fact init USB *much*
> later and be quite happy. Sorry I don't have full answers until I get
> back to this. But USB does 'start' each port within the initcall which
> seems to take time. Maybe it is at bottom a driver issue?

Then load the usb module from a thread after init starts up and you
should be fine for boot speed, right?  That's what other distros did
with no known ill side effects.

greg k-h

  reply	other threads:[~2012-01-27  0:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-19 23:37 [PATCH] usb: Use a workqueue in usb_add_hcd() to reduce boot time Simon Glass
2012-01-20 15:46 ` Alan Stern
2012-01-20 23:47   ` Simon Glass
2012-01-21 16:11     ` Alan Stern
2012-01-24 16:57       ` Sebastian Andrzej Siewior
2012-01-24 17:22         ` Greg KH
2012-01-26 23:48           ` Simon Glass
2012-01-26 23:51             ` Greg KH
2012-01-26 23:57               ` Simon Glass
2012-01-27  0:07                 ` Greg KH [this message]
2012-01-27  2:45                   ` Simon Glass
2012-01-23 16:14     ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120127000723.GB14678@suse.de \
    --to=gregkh@suse.de \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=sjg@chromium.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.