Re: [PATCH RFC] USB: Add HCD fastboot

[Simon Arlott]

On Fri, August 8, 2008 10:24, Rene Herman wrote:
> On 06-08-08 20:40, Simon Arlott wrote:
>>>> Ok - so there could be some big improvements to be had by making the
>>>> hcd init happen as early as possible and the device initcalls later?
>>>
>>> Maybe.  Perhaps a better approach would be to make the device driver
>>> initcalls before there are any devices for their probe routines to
>>> block on.
>>
>> What about this?
>>
>> The Makefiles become a bit messy, but by moving things around I get the
>> desired effect without splitting their initcalls.
>>
>> [    7.941890] Write protecting the kernel read-only data: 5656k
>> [    5.437709] Write protecting the kernel read-only data: 5656k
>>
>> 2.5s faster, which is almost half the boot time.
>>
>> Signed-off-by: Simon Arlott <simon@xxxxxxxxxxx>
>
> Interesting... I haven't been able to get stable improvements, with all
> USB kernel modules built-in, just a USB mouse on OHCI and otherwise a
> switched of USB HD on EHCI and usb-storage, but I do get the idea that
> with your parch, I "get lucky" more often.

It does depend on what else is running... I have e1000 (500ms) and
sata_nv (2200ms) so there's plenty of additional time for usb devices
to finish initialising.

> I have knfsd as a module and it loads through the exportfs trigger
> during bootup and outputs the last message to my dmesg:
>
> 4 boots without your patch: 6.12, 6.41, 6.38, 6.34 seconds
> 4 boots with              : 5.39, 6.33, 5.37, 6.34
>
> Booting with the external HD switched on adds a tiny bit to the actual
> kernel startup time -- completely repeatable 2.62 seconds until freeing
> init code with the HD off versus 2.73 with it on -- but doesn't seem to
> change the picture otherwise...

usb-storage by default delays 2 seconds before trying to use the device,
so it won't add much time itself if there's already an driver initcall
trying probe for devices it supports.

> Would those results make sense you feel? I'm not looking forward to
> putting an actual statistical analysis on it ;-)

I suggest adding initcall_debug=1, it'll show how long the usb and other
initcalls take to run. You should see the first usb device driver initcall
take a second or two to run (without the patch). Maybe I'm just badly
affected by having HCDs with 10 ports (of which only 4 are physically
usable...).

dmesg|grep initcall\
|sed -e 's/.*initcall \([^ ]\+\( \(\[[^]]\+\]\)\)\?\) returned [^ ]\+ after \([^ ]\+\) secs/\4 \1/'\
|sort -n

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