Posted by mcortese on Thu 26 Feb 2009 at 15:11
In the quest for the fastest boot ever (see Booting Debian in 14 seconds), you may want to consider setting the variable CONCURRENCY=shell in /etc/default/rcS, recalling from your your theoretical studies that "Parallel is faster than Sequential."
The results you get can fall short of your expectations if you don't also reorder the boot sequence. And if you have installed readahead, you may even have unpleasant surprises...
When you install readahead, it places an init script in /etc/init.d and its symbolic link /etc/rcS.d/S02readahead. As long as the scripts in /etc/rc?.d directories are executed in lexicographic order, this script is executed after S02mountkernfs. This is fine, because readahead actually depends on /proc being mounted, which is exactly what mountkernfs does.
But what happens when, as a consequence of CONCURRENCY=shell, all scripts with the same priority are run in parallel? Then readahead and mountkernfs, both with priority 02, are launched together, and the latter may or may not mount /proc before the former requires it.
In fact, readahead must be run after mountkernfs (priority 02) but before udev (priority 03). Lacking fractional priorities, the only solution is to "promote" udev to priority 04, which, in turn, triggers a "+1" promotion for all the subsequent scripts that depend on each other, namely: mountdevsubfs (from 04 to 05), and keymap and bootlogd (from 05 to 06).
Now your boot sequence is sane, but still suboptimal. To get any benefits from the concurrency, as many scripts as possible must share the same priority, so that they can be parallelized. Opportunities for optimization can be found in six different places:
Please note that I have intentionally skipped hwclock since I never got to understand what it is intended to do that hwclockfirst doesn't already do. In any case, I got rid of the time-consuming hwclock and hwclockfirst all together when I compiled RTC support into the kernel.
To summarize, this is how your /etc/rcS.d should appear, with same-priority scripts grouped on the same line:
S01glibc S02hostname S02mountkernfs S03readahead S04udev S04procps S05mountdevsubfs S06bootlogd S06hdparm S06hwclockfirst S06keymap S10checkroot S12ifupdown-clean S12module-init-tools S12mtab S12udev-mtab S30checkfs S35mountall S36mountall-clean S37mountoverflowtmp S38readahead-desktop S39ifupdown S39urandom S39x11-common S40networking S45mountnfs S46mountnfs-bootclean S50alsa-utils S50bootmisc S50console-screen S50sudo S99stop-bootlogd-single
Having done such a nice job with rcS.d, what about optimizing rc2.d as well? The goal here is different, though. What you should really be interested in, is to bring up the login screen as soon as possible, and let all the rest follow at its own pace.
I'll assume that you have GDM to take care of your login (configuration of other display managers should be even easier, thus is left as exercise for the reader).
As Arjan and Auke teach us the first think to do is to identify the "critical path" that leads to S30gdm as soon as possible. Here it is:
S10sysklogd -> S12dbus -> S24hal -> S30gdmI would also add S11klogd, to be sure to catch all kernel messages. All the rest can be run afterwards:
Again, this is a summary of the /etc/rc2.d directory after the cure:
S10sysklogd S11klogd S12dbus S24hal S30gdm S31system-tools-backend S40acct S40avahi-daemon S40openbsd-inetd S40ssh S45cups S45saned S89anacron S89cron S98rc.local S98rmnologin S99bootchart S99stop-bootlogd S99stop-readahead
Please note that, depending on the software you have installed, your list may be different. For example, you might have xinetd instead of openbsd-inetd, and so on.
I hope this works for you as it worked for me, polishing away another 3 seconds from my boot time!