We will continue the work done for Ubuntu 9.04 to reduce the time to boot the operating system. There will be a switch in focus from attempting to reduce the current time as much as we can, to setting a target time for the total boot and a budget which each component must not exceed to reach it. This work will continue across both the 9.10 and 10.04 development cycles.

Release Note

As part of our ongoing effort to increase performance, Ubuntu 9.10 boots even faster.


There are many important rationales for the continued focus on the boot performance of Ubuntu:


This specification is largely unrelated to effort to reduce the time to suspend and resume the system while increasing the reliability of that process. Both have similar rationales, and both are desirable.


The new boot performance target is a 10s boot for Ubuntu 10.04

Ubuntu 9.10 (karmic) will attempt to step as much in this direction as possible, but is not expected to reach the target.


10s is a good number, especially for a generic, hardware agnostic, non-stripped down Linux distribution. From that starting point, development teams will be able to customise and tailor Ubuntu for specific hardware - and the OEM team will be able to produce custom Remixes of Ubuntu that boot even faster.

I think it likely that we'll match Moblin's 5s benchmark on similar hardware, with a device-tailored Moblin-based remix of Ubuntu.

(The 2s benchmark is afaict mostly aimed at the Automotive industry, and for specialist devices rather than computing devices)

And just to affirm something we've stated before; this benchmark time is to a fully logged in desktop (auto-login) with an idle CPU and Disk. Deferring services is not an option unless done properly (ie. switching services from startup to on-demand activation).

Reference Platform

The reference platform for this target is a Dell Mini 9 netbook, the slow CPU and fast SSD makes this an excellent "middle of the road" machine. Some people's machines will be slower, some will be faster.

If you're comparing bootcharts on the reference platform, they will be comparable with those produced by other developers working on boot performance. If you're comparing bootcharts on a different platform, be sure not to compare the numbers with others - just the shape.


One of the primary assumptions is that the most important thing we need to start, as soon as possible, is the X server. Almost everything that we ultimately want running needs the X server.

The user's applications, desktop, panel, file manager, etc. all need the X server.

If a service is not a dependency of the X server, it can be started once the X server is at least initialising itself (available CPU or I/O permitting).

The dependencies of the X server are:

In otherwords, "udev". udev has no real dependencies other than being out of the initramfs.

This means that the only thing holding us up loading X is udev, and the initramfs. Some encouraging work has been done to udev which I hope to talk about in a future mail, so really the problem is the initramfs.

The initramfs has one job: to mount the root filesystem.

However we've ended up putting rather a lot of other cruft into it that we really don't want.

The reason we don't want it is that there's a logarithmic penalty for adding things to the initramfs, because not only does it have to be loaded from disk, but it has to be decompressed, unpacked and cleaned up afterwards.

A slight side-effect of this is that in the default case, there will be no splash screen. I hope to demonstrate that X can be started sufficiently fast that we don't need one.

Obviously we'll need something for when we need to check a filesystem, or ask for a passphrase to decompress one, but we can start it in that case.


For this next phase of boot performance work, we will take a new approach. Instead of slimming the system down as we can, we will instead set budgets for each phase of the boot and work until that phase is below that budget.


FoundationsTeam/Specs/KarmicBootPerformance (last edited 2009-06-15 11:13:06 by quest)