No I'm not using a dependency-based init. My approach so far has been to find the slow bits and remove the bug that makes it slow: sequential is fine as long as the individual steps are fast. Also, since X takes several seconds just probing the hardware, and I'm not (yet) changing that, many of the delays are hidden just by starting X earlier; I'm unsure why Debian starts xdm at S99. The "sore thumbs" are currently setting the clock, which Debian does twice and each time waits until the second ticks over, and the udev coldplugging. Arjan has sidestepped udev with a pre-populated /dev but I'm considering something a bit less extreme or a bit more automated - or simply working out why udev takes so long just to call mknod a few times.
Posted Oct 15, 2008 20:30 UTC (Wed) by nix (subscriber, #2304)
[Link]
If you're using the default rules, it's probably calling modprobe a bunch
of times for modules you don't have.
Bits from the Debian Eee PC team
Posted Oct 15, 2008 21:32 UTC (Wed) by endecotp (guest, #36428)
[Link]
Everything that it needs is built in to the kernel. I have the impression that during coldplug it still calls modprobe, but that that's a no-op as no module is loaded. I'm not sure how much time is spent doing that and whether it's worth trying to fix it; it's clearly spending more time bringing up the network, which could be postponed until later in the boot and run asynchronously.
If anyone's curious, I have put bootgraph/chart here which you can compare with Arjan's from his LPC presentation:
Posted Oct 15, 2008 22:02 UTC (Wed) by nix (subscriber, #2304)
[Link]
It eliminates dozens of forks, at least, and if you know you have no
modules that's all wasted time. (It takes nearly a second to do those
modprobes on my 1.2GHz Athlon IV.)
Bits from the Debian Eee PC team
Posted Oct 20, 2008 5:47 UTC (Mon) by branden (guest, #7029)
[Link]
Phil,
xdm starts at S99 for purely historical reasons. It was that way when I took over the X packages from Mark Eichin in 1998 and the closest thing to an articulated reason I ever came up with, or heard anyone else offer, for leaving it there was the usual exceptionalism having to do with X. The default configuration is to run a local X server, of course, and that will go poke the hardware rather hard (which most daemons don't do).
I think in the years since someone has filed a bug requesting that xdm (and the other *dms) be kicked down to S90 or so. Certainly once mode-setting gets into the kernel, I think any remaining reasons for leaving xdm at the tail end of the init sequence will have been vitiated.
You should certainly raise this issue with the current X Strike Force when you feel the time is ripe. xdm is where it is almost entirely due to inertia.
I find the EEE 1000 model very tempting, so I am watching your work with great interest and appreciation. Thank you for your efforts!