KarmicBootPerformance

Summary

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.

Rationale

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

  • Boot performance improvements are an important marketing story for comparing Ubuntu to our competitors. Users have become used to each new software release requiring more memory, faster computers and taking longer to do things. Ubuntu releases are instead faster, work on a wider range of hardware and reduce memory footprints.
  • It's an important sales story for Canonical when bidding to have Ubuntu or Ubuntu-based systems such as Ubuntu Netbook Remix installed by default on Netbooks or Laptops. A fast boot provides a competitive advantage over other operating systems.
  • The initial "wow" user experience of a fast boot can help make a new user much more positive about the system, so more likely to continue to try it and less likely to want to return to an other operating system.
  • The process of reducing boot time is strongly related to the process of reducing the bloat and complexity of the operating system, a fast booting system is a system with a reduced memory footprint and reduced complexity which are worthwhile results in their own right.
  • A hefty majority of the boot time is actually the desktop login time. Even with good suspend and resume times, we want the times for switching users and opening a guest user session to be short.
  • Developers and power users following development releases or testing stable release updates often need to reboot, a faster boot means that they're down for less time
  • Reduced downtime of data centre servers.
  • Reduced activation time of operating system instances in the cloud.

Scope

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.

Target

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.

Rationale

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.

Design

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:

  • a writable, mounted filesystem
    • - we'll do this work as udev probes the block devices
  • the Kernel framebuffer driver
    • - loaded by udev
  • udev
    • - replacing HAL as the basis for input hotplug
  • the hostname set
    • - done very very very early

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.

Budgets

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.

  • 2s Kernel and initramfs.

    • This includes both, since arguably the need for an initramfs is a kernel implementation detail anyway (the kernel can mount the root filesystem itself in many circumstances)

    2s Plumbing

    • This is for driver loading, filesystem mounting, general busy work, etc.

    2s X.org server

    • Includes the display manager that actually starts it. Also includes any services required for the user's session that can be started alongside the X server

    4s Desktop session

    • Everything from the window manager, file manager to the panel and its applets. Also includes any services they require.


CategorySpec

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