On Fri, Jan 07, 2011 at 10:42:02AM +0100, Martin Mueller wrote: > Hi Greg, > > thanks for the quick reply. > > > > 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. > > > with > > > > > > http://lwn.net/Articles/299591/ > > > > > > removes the delay but could cause other issues. We need both compiled > > > in and can not run them as modules. Is there any other recommended > > > procedure to increase start-up time? > > > > Yes, do like other "sane" distros do and don't stop the rest of the > > system from coming up when you are waiting for USB to get initialized :) > > > > Seriously, this should not be an issue at all, why are you forcing your > > boot sequence to wait until after this is finished? Your system should > > be off doing other things at this point in time while those delays > > happen, right? > > Do you mean we should have USB EHCI/OHCI in modules? That is not an option > as said above. No, actually if you have the code built in, it boots faster. I have done a lot of testing and tuning to get boot speeds down on a number of laptops that ship with Linux that my employer supports. We ended up getting Linux booting to starting init in way less than a second (usually about .5 seconds on average, throw in solid state media and it goes even faster.) > 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. > 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? Oh wait, what kernel version are you working on here? That will make a huge difference as to your boot speeds. > 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. > > Thanks, > Martin > > [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. thanks, greg k-h -- 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
