Hi Greg, > > > > we are working on making the Linux Kernel (2.6.34) boot faster on an > > > > embedded ARM machine. One significant delay is caused by the 50ms > > > > TDRSTR minimum reset time required by USB spec. Starting both OHCI > > > > and EHCI creates a 100ms sleep in total. Running them in threads e.g. > > > > Some more details: > > > > The 50ms delay we talk about here is caused by msleep() in the > > (ECHI-/OHCI-) driver initializations. These are called while the kernel > > starts, even before the root file system is mounted. > > That's fine, you should be off doing other things while this sleep > happens, right? Like probing your disk drive, bringing your video card > up and other fun things. Maybe that is an issue with our ARM system. The USB EHCI/OHCI init happens pretty much towards the end of the boot sequence. Seems there is nothing left to parallelize that runs in threads. If that is the case would it be smart to put EHCI/OHCI init earlier into the boot process to have it wait in parallel or put it into threads itself? At minimum both could wait 50ms in parallel instead of serial. > > Using a HW trace and initcall debug [1] we can see that while in this > > msleep() nothing is executed in parallel. The system is just idling at > > this time (during kernel start). In sum this results in > 100ms delay > > until the root file system is mounted due to the consecutive start of > > EHCI + OHCI (both msleeping ~50ms). > > > > Using Arjan's patches > > > > http://lwn.net/Articles/299591/ > > esp. "fastboot: turn the USB hostcontroller initcalls into async > initcalls" > > Ick, you do realize that those are very old and you shouldn't need this > for modern kernels, right? Yes. We do not want to use that patch - it just showed us that things go faster if the USB EHCI/OHCI are put into parallel threads. It seems that after Arjans patch appeared some USB bootup waits are being done parallel now, like the 100ms TATTDB delay [1]. Still there could be some more to get. > Oh wait, what kernel version are you working on here? That will make a > huge difference as to your boot speeds. > > You said you are using the .34 kernel, nevermind. You shouldn't need > these patches for that kernel, but do note that the .34 kernel is quite > old, and that newer kernels should boot even faster. > > But all the work I did was on x86 machines, not ARM, so perhaps you have > other delays and interdependencies that I never saw on x86. The boot > graph will show you what you need to parallelize better than just > looking at log messages. Yes, exactly. Using Arjan's patches, this better parallelization was done and we saw that this helped to solve the issue we see. But as Arjan's 'hackish' patches are not accepted in mainline: How do we do this better parallelization? I.e. what do we have to modify how for better parallelization of the USB init in the stock kernel? > Do you have the output of one of them that you can share? > > > the boot time is improved by these > 100ms. If we understand correctly, > > they let the USB init (and with this the msleep()) be executed with the > > rest of the kernel initialization in parallel, avoiding the kernel to > > idle while msleeping in the USB init. > > > > [1] Using initcall debug http://elinux.org/Initcall_Debug : > > > > 58461 usecs [ 0.710000] initcall ohci_hcd_mod_init+0x0/0x6c returned 0 > > 50882 usecs [ 0.650000] initcall ehci_hcd_init+0x0/0x94 returned 0 > > 36067 usecs [ 0.520000] initcall tty_init+0x0/0x100 returned 0 > > 23210 usecs [ 0.580000] initcall brd_init+0x0/0x19c returned 0 > > 20947 usecs [ 0.540000] initcall pty_init+0x0/0x424 returned 0 > > 20701 usecs [ 0.460000] initcall aio_setup+0x0/0xb4 returned 0 > > ... > > Have you used the kernel boot chart that can graph what your boot > sequence is really doing? You should not have any delays, with other > things happening while the usb init starts up. The script is in > scrips/bootgraph.pl and I highly recommend using that to debug this type > of thing. Just looking at the logs by hand really doesn't show what is > going on. We see the same in the bootgraph as in the hardware trace. There is nothing done in parallel to the msleep(). Thanks, Martin [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8520f38099ccfdac2147a0852f84ee7a8ee5e197 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
