Boot speedups
From Smop.co.uk
Originally these were blog entries, but I've moved them here as I think it's a more useful location for them.
Contents |
Day 1
First up is Kexec which lets you boot one kernel directly from another (i.e. without going through the BIOS). This saves a minimum of twelve seconds on my machine - add to that any timeouts that can be cancelled such as booting from CD/floppy/network or boot loader prompts.
Unfortunately there are no official Debian packages of this. (Update: there are now!)
grub
I've also changed from lilo to grub as my preferred bootloader. Whilst I personally find lilo easier, grub is much more powerful - editing boot options if a boot fails without rebooting is very nice. It also offers powerful searching facilities, but these are a bit buried in the manual IMO. So whilst grub won't make booting the machine any faster, it might make testing (e.g. Xen) faster :-)
monit and runit
I've had a quick play with these replacements for the usual sysV startup scripts. Both are far nicer, however Debian doesn't play nicely with them. It wouldn't be a huge amount of work to move over, but I'd rather not move until it's decided what the standard will be. All the distributions will probably move away from the runlevel concept in their next major release.
dash shell
I've just changed /bin/sh to point to /bin/dash rather than /bin/bash and it knocked three seconds off the time (0:39 vs 0:42).
/etc/init.d/rc speedups
I've made a few modifications to /etc/init.d/rc so that it starts services in parallel as far as possible. For instance it will start all services "S20...." in parallel, but then wait for them all to finish before starting "S21....". This reduced bootup time from 0:39 to 0:35.
runlevels
My last attempt was to split scripts up into "immediate" and "delayed" scripts. The "delayed" scripts I moved into runlevel 3 (Debian is normally in runlevel 2 and runlevels 2-5 are all identical). These scripts are server scripts such as samba and ntpd which I want running, but don't need to be started immediately. I then added a S99telinit which waits thirty seconds and then runs "telinit 3" which will kickstart the delayed scripts which I left solely in runlevel 3. Due to the way /etc/init.d/rc works, it is sufficient to remove the symlinks for the delayed scripts from /etc/rc2.d.
Update: unfortunately package updates will put these back, you need to rename them to KxxService. Shame as the stop scripts can be pretty slow (read badly coded).
Final thoughts
Well it's time to go to sleep, overall not a bad effort - a 40% reduction in time to gdm starting - 22s vs 36s. There is more that can be done - and we havn't got anything complex like read-ahead or ramdisk caching going on yet (nor do I intend to). Looking at the full bootchart there seem to be some more opportunities - hwclock takes a long time but I was loathe to move it. However the worst is a few seconds jump in the logs, so it's worth investigating to see what the gain might be. Similarly dhclient. There are even some sleeps that seem to be delaying matters.
bootchart
Some bootchart pictures for you to enjoy:
- orginal (42 seconds, gdm at 36 seconds)
- dash as /bin/sh (39 seconds, gdm at 34 seconds)
- patched rc (35 seconds, gdm at 31 seconds)
- delayed scripts (27 seconds, gdm at 22 seconds)
Day 2
sleeps
There are a few sleep commands noticeable in the bootchart (particularly if you use the "-n" (no prune) option. There is even a "FIXME" which I have patched in /etc/hotplug/usb.agent.
hwclock
For some reason, Debian has two scripts which invoke hwclock to read the PC hardware clock and set the Unix system clock from it on boot. Firstly, hwclockfirst.sh reads the clock, then it reads it again, then various other scripts are run (but nothing that seems related) and then hwclock.sh is run and the clock is re-read. So I've removed /etc/rcS.d/hwclock.sh and made a patch to hwclockfirst.sh to simplify the code and remove the superfluous call.
Together these changes have knocked another two seconds from the boot time as you can see in the bootchart (boot in 25 seconds, gdm in 20 seconds).
networking
DHCP can take quite some time - and a variable amount at that (I am running a wireless network here which might make that worse). By backgrounding this another two seconds can be saved. I don't use NFS mounted filesystems - if you do this will make these fail unless you move them later on. One item I have left to check is whether WPAsupplicant (a wireless privacy program) is going to have problems with this. This is where the lack of dependencies in the current system is evident. As usual, there is a graphical bootchart to see, total time now 23 seconds, gdm in 18 seconds).
reordering
My nvidia card takes a little while to start up (the screen goes blank for a fair few seconds), so I've actually reordered the files in /etc/rc2.d - I now have S13xfs-xtt and S14gdm. This makes gdm start another second or two earlier (25 seconds overall this time (there is some variance in these graphs) and 18 seconds for gdm) - as usual, there is a chart.
This is probably the last I'll be doing regarding fastboot. I seem to have come across one buglet using kexec - ehci (high speed USB) refuses to initialise, leaving me without a working USB TV card until I do a proper reboot. This is with linux 2.6.13-rc3-mm1, I'll look for patches.
More notes
Notes from later:
- mounting filesystems can take some time (and I/O)
- so if you can mount FS's later, do so
- grep sleep in /etc/init.d/* and weep
