On Wed, July 30, 2008 20:41, Alan Stern wrote:
quoted text
> The timings in the boot log agree with your "Without fastboot:"
> figures, so I assume that's the log you attached.  The only timings at
> issue here are ehci_hcd_init and ohci_hcd_mod_init.  It's not clear
> that the with-fastboot and without-fastboot values are directly
> comparable; during startup there's a lot of activity, and interrupt
> handlers can throw the timings off.

I wasn't suggesting comparing ehci_hcd_init/ohci_hcd_mod_init times,
with fastboot I'm assuming it may manage to take a lock those need in
the main initcall process and delay hcd inits.

quoted text
>> It looks like usb device driver init requires it to immediately block and
>> wait for all devices to have completed init
>
> Which USB device driver init are you talking about?  Your log includes
> usblp_init, usb_stor_init, usb_usual_init, hid_init (for a USB mouse),
> and snd_usb_audio_init.  Each one completed before the next one
> started; none of them blocked waiting for any devices (other than their
> own, of course) to finish initializing.

Yes - and that's the point. The initcall process when it reaches usb/ is
this:
1. ehci_hcd_init
2. ohci_hcd_mod_init
3. usblp_init

There is nothing else to run between 1-2 and 3, so there is no opportunity
to initialise devices in the background and usblp_init blocks for a while.

If ehci_hcd_init and ohci_hcd_mod_init were moved up to before sata/ide/net
but usblp_init was kept after these then the devices should be ready by the
time it gets there.

quoted text
>>  - so regardless of where we
>> put the usb/ directory in the initcall order, it will always wait a while
>> because the drivers will be immediately after the hcd init...
>
> No, you're wrong.  To prove it, try patching the start of hub_events()
> in drivers/usb/core/hub.c like this:
>
>  	 * Not the most efficient, but avoids deadlocks.
>  	 */
>  	while (1) {
> +		ssleep(5);
>
>  		/* Grab the first entry at the beginning of the list */
>  		spin_lock_irq(&hub_event_lock);
>
> Then see what happens.

I'll try this tonight, but all I'd expect to see is the background thread
take longer to do anything?

quoted text
>> perhaps
>> if we moved the hcd init to before net/, sata/, ide/ etc. (all the things
>> that take time themselves) but left usb device drivers to the end it
>> would actually get the benefit of that separate thread.
>
> They are already running in a separate thread.  Of course, the
> different threads will contend for CPU resources -- just putting things
> into multiple threads doesn't mean they will necessarily run
> concurrently.

There's a lot of delays going on during sata/ide/net init, waiting for
the device to do something - usb init continues concurrently.

quoted text
>> I don't have the time to rework how usb/ is linked in order to try that,
>> but moving usb/ to before net/ and sata/ while making all the usb device
>> drivers that get used be late initcalls could be used to test it.
>
> You seem to have a completely mixed-up idea of how the USB stack works.
> All the device drivers you're worried about are initialized within the
> khubd kernel thread.

The usb device driver initcalls aren't initialised by khubd and they're
definitely blocking on the khubd device initialisation [for that device,
as you said earlier] being completed.

-- 
Simon Arlott
--
unsubscribe notice
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/