Speedboot explained

For those of you not following Mandriva Linux development closely, we just released Mandriva Linux 2009 Spring Beta and this is our first release featuring speedboot feature, in its initial phase.



Booting fast, is it important ?
Boot time has been a hot topic for the past few months in Linux community, either by chip and SSD manufacturers who want to show how fast their hardware can go when software is fixed properly (Moblin fastboot) or even by distributions, mostly on Netbook and OEM, such as various Mandriva Linux based products, like Hercules eCafé, G-dium, TouchDiva which are using Mandriva finit.

However, most of those initiatives are focused on fixed hardware configuration and software install, which ease boot speed optimization according to system specifications.

Unfortunately, on a generic distribution where many features are available and might be enabled or not, based on user choices, not all optimisations can't be applied blindly.

This is why we have created speedboot for Mandriva Linux 2009 Spring.

What is speedboot ?

Speedboot is a specific boot time mode on a standard Mandriva Linux 2009 Spring where graphical system is started as early. This mode allows users to interact with their system much earlier than it was possible before, so they don't feel frustrated because their system isn't ready yet.

In Speedboot mode, some tasks are done very early in the boot process, other are delayed after graphical display manager has been displayed, and some tasks are ignored completely.

Speedboot has been designed to be transparent for our users : if system meets some criterias (not using network based authentication, not using encrypted partitions, ...), speedboot will be automatically enabled and used, with a fallback mecanism, in the event display manager could not be started properly, so standard (ie slow) boot would still be used to start display manager (for instance, if you boot on a new kernel and your dkms driver haven't been rebuilt yet). Of course, users will also have the possibility to completely disable speedboot if they don't like it.

But you are cheating, you are slowing boot process by running stuff in the background !!
I'm not sure it is cheating, but it is true we are deferring some tasks which used to be executed before display manager. It is a matter of perception for users. For years (since 2002), Mandriva have been starting display manager as soon needed services for X and display manager where running, to give a better user experience in the boot process, so some services (network, ssh server, etc..) were already being started in the background. We improved this system by using a parallel initscript system (prcsys) in 2006, allowing to reduce again boot time and in Mandriva Linux 2009.0, we tuned the system again and added readahead and preload, which, in most cases, reduced again boot time.

However, we also discovered those techniques didn't work everywhere : not everybody has a fast harddrive or SSD, so readhead could sometime slow boot time. Based on user configurations and system power, parallel initscript could sometime "clutters" initial boot time (since some services had no dependencies on other services, they were started early and precious CPU cycles (or IO) were used by them instead of the critical path for display manager startup.

So, we needed to find a path between a fully sequential system (à la finit) which can't be generalized on everybody system, and a fully parallel system (à la prcsys) which can't be optimized easily. We already did some of those optimisation for Mandriva 2009.0 and speedboot is the next step.

So, what do you really do in speedboot mode ?
We are still using standard initscripts, which have been modified a little to do the following :
- start udev almost immediatly after rc.sysinit is up, but do not do ask for coldplug events (this is what eat a lot of CPU on standard systems). Instead, ask udev to coldplug specific components which are needed for Xorg to start. And do this in the background
- check filesystems
- mount filesystems
 - in a new specially created runlevel (and in background) start display manager and its dependencies (syslog, dbus, hal, acpid)
- do some cleanups on various directories

- wait until display manager is up and running (with a timeout, just in case) and then continue the standard boot process in runlevel 5 (using prcsys to use parallel init)
- do not use readahead (nor sreadahead) : atm, I've been confusing on average harddisk and readahead doesn't help in that case, because we are already using too much IO on the disk and even idle IO are slowing the boot. I'll need to check on fast harddrive and SSD and maybe only enable readahead depending on the disk speed (but I'm not a fan of this, because it implies running a disk speed test at some point)

How can I test speedboot ?
That is quite simple : download Mandriva Linux 2009 Spring Beta release, install it and add speedboot to your kernel cmdline (either manually on in your grub / lilo configuration). Be aware speedboot can cause issues like changing kernel version (because it is started before dkms). Those issues will be fixed in future pre-releases of Mandriva 2009 Spring, as well as automatic activation of speedboot. Anyway, if you found issues, please fill bug reports on our bugzilla, against initscripts components or email cooker mailing list.

You lied, bootchart says my boot time is longer with speedboot than without
Well, unfortunately, bootchart is measuring the entire system boot time and with speedboot, we are favoring X early startup (what I call "perceived boot time") at the expense of total boot time (ie when all services are up and running). If you want to compare bootcharts with and without speedboot, look at timing for gdmgreeter (or kdmgreeter) startup. This will mean system is ready for login. On average, we found a gain of 10s, which means you can get graphical login available between 8s and 20s (this varies on your system specification). You can check some results here : you get kdm greeter in 12s instead of 23s. And you can also check the influence of using ext4 vs ext3, which isn't giving that much gain some people thought it would : just 1s with speedboot for kdm greeter.

But you are slowing the desktop login !

Yes, we might, but not that much. Possible solutions would be to start the various services with ionice / nice, but it is a little dangerous since they should be renice back to standard niceness once login is finished and you can't be sure to be able to do that without any leftover. Some people also suggested to us at command but this would not integrate transparently with initscripts provided by various services.

Why didn't use upstart ?
We tested it but it is still very young, changing a lot, breaking its configuration file between major releases and to be able to have a full event based system would require rewriting all initscripts to upstart format, without being sure we would have gain. So, for now, we are keeping with standard technologies, which are LSB compliant as a bonus.

We hope you will like speedboot and are waiting for your feedback, either on cooker mailing list or bugzilla.

Enjoy !