BootPerformance

Differences between revisions 39 and 40
Revision 39 as of 2009-07-21 23:34:58
Size: 13411
Editor: 99-156-85-10
Comment:
Revision 40 as of 2009-07-24 17:33:54
Size: 13508
Editor: 194
Comment:
Deletions are marked like this. Additions are marked like this.
Line 72: Line 72:
Line 113: Line 114:

== Win7 Comparison Data ==
See http://people.canonical.com/~cking//graphs/boot-graphs.html

With this being a feature spanning multiple releases, we thought it best to have a single point of reference for all the work we are doing and plan to do in the future.

Rationale

(*pulled from /FoundationsTeam/Specs/BootPerformance)
As time has passed, the boot performance of home computers has steadily worsened; it is not longer unusual for a desktop operating system to take well over a minute to be ready from the time the user first presses the power button.

While this has been somewhat acceptable for desktops, where the user at least expects it to take a long time, increased focus on smaller and more mobile devices means that something needs to be done.

For a netbook or mobile device to be truly useful as a convenient, lightweight, computing platform; the boot must take as little time as possible so that the system is immediately useful for the user. Any longer, and they may as well use their desktop or full laptop.

Why is This Important?

(*taken from Scott James Remnant's UDS Karmic Presentation)
The question can still be made, "But why is boot speed so important? That is, why should we invest time and effort in this?" There are multiple reasons for doing so:

  1. Engineering Excellence - Fast boot means you have a light and lean OS, which means reduced overheads for the system, better for Live CD, mobile, etc.

  2. Netbooks - Boot speed is important to OEMs when choosing which OS to pre-install on their netbooks. Faster boot means more netbook pre-installs, which can then lead us (Ubuntu) to laptop pre-installs. In addition, since netbooks require a lighter platform, this allows for an easier transition to Mobile devices, if ever needed in the future.

  3. Competitive Advantage - In the past, a certain "other" OS always seemed to require more CPU power for each new release. This has obviously not been a good thing for users, and thus the maker of this OS has now recently touted improved boot speed as a reason for switching...we must be as fast, if not faster, to support our point of Linux being the better OS.

  4. Suspend/Resume is Not the Answer - Yes, a fast suspend/resume cycle is extremely useful, not to mention very cool Wink ;) , but sometimes you can't suspend. For example:

    • on airplanes, where your laptop is supposed to be OFF during takeoff, not asleep...and not with wifi/bluetooth turned off.

    • when testing or developing for the OS, where sometimes you simply have to reboot to recover from a crash, test a new kernel, etc.
  5. Cloud Computing - Fast boot is important for the cloud. When you're paying for uptime, you don't want to be waiting for your cloud instance(s) to boot (and paying for it!).

  6. Data Centers - Fast reboots in the data center mean less downtime, even with a backup, that's less time worrying about something else going wrong.

Use Cases

(*pulled from /FoundationsTeam/Specs/BootPerformance)

  • It should be possible to power off desktops and work stations over night, to conserve power and energy. Lost time in the morning to switch them back on is undesirable.
  • Laptop users want to use their computer as soon as possible without waiting, even though the hardware is lower powered and slower, it should boot quickly.
  • Netbooks are marketed to be convenient and portable Internet and computing devices. They must not take any significant time to boot, otherwise it becomes more likely the owner will simply use their desktop computer instead.
  • For Ubuntu to be suitable for mobile devices such as cell phones, it must boot quickly to give the "instant on" experience most commonly expected with such commodity devices.

Plans for Jaunty (9.04)

Our approach for this release is to look at what we have, profile and chart it, and identify areas for improvement. We will iterate over this process steadily reducing the time it takes for the system to boot. Our goal for this release is to have a fully functional system, i.e. no sneaky backgrounding to make it "appear" booted, up and running in 25sec (or less). Our reference platform is the Dell Mini 9, as it has the Intel Atom processor and an Solid State Drive (SSD) disk, so makes an excellent benchmark for the Netbook form factor.

Detailed Changes

*In No Particular Order

DESCRIPTION

STATUS

Update the kernel config to improve performance

Done

Optimize the boot up process by parallelizing events where possible

Done

Fix seahorse agent timeout

Done

Investigate why udevadm is taking too long, and improve where possible

Done

Reduce the startup time for compiz

Done. See the associated Feature Freeze Exception

Apply Xserver performance patches found in Moblin image, if applicable

Deferred to Karmic. By the time we got them, it was too risky to implement in the release, as a lot of the changes were kernel related and rejected by upstream as either being untested on non-Intel graphic chipsets or being too netbook specific. See associated Feature Freeze Exception

Mode-switches and console changes are known to be expensive, in addition they create the intermediate VTs, so start usplash and X on tty1

Deferred to Karmic.

Figure out why we set the hardware clock several different times from different places and fix where possible

Done

Change the nm-applet connecting animation to something that doesn't adversely affect performance

Deferred to Karmic.

Add new and faster module-init-tools upload that uses binary indexes

Done. See the associated Feature Freeze Exception

Set console font, keymap and utf-8 mode from udev while usplash is running

Deferred to Karmic. See associated Feature Freeze Exception

Update X to save the results of xkbcomp rather than regenerating every single time the server is started

Didn't improve performance...or work. Wink ;) See associated Feature Freeze Exception

Eliminate various calls to modprobe in initramfs and initscripts where they're not needed

Done. See associated Feature Freeze Exception

Move some scripts out of rcS and into rc1-5 so they can run while X is up

Done. See associated Feature Freeze Exception

Eliminate some unnecessary init scripts (ie. wacom, powernowd)

Done. See associated Feature Freeze Exception

Fix the hostname tool so an init script is not needed

Deferred to Karmic. See associated Feature Freeze Exception

Move from readahead-list to sreadahead

Done See associated Feature Freeze Exception. We need resolve an outstanding issue with sreadhead reducing performance on machines with rotary disks (See associated Feature Freeze Exception. Until this is resolved, we will not use sreadahead by default.

Identify any bottlenecks in the gnome login that we can fix

Done. See associated Feature Freeze Exception

Look at some patches from SuSE that speed up gconf and gnome-settings-daemon

Deferred to Karmic.

Bootcharts

This section will be updated to show our progress towards our goal of 25sec (or less) for Jaunty on a Dell Mini 9. For reference, we will compare our results to the performance of the latest Moblin v2 development release on a Dell Mini 9. It should be noted that while the boot time is much faster, the current Moblin development image is much more hardware specific than a standard Ubuntu Desktop image, and does not provide certain functionality needed for a Dell Mini 9 netbook, e.g. the wireless adapter is not supported, keyboard mapping not fully functional, etc.

Current MoblinV2: 12sec - Alpha2

Current Jaunty: 25sec (using compiz)

  • 25sec: Includes previous changes with additional improvements, using metacity.

  • 30 sec: Includes previous with seahorse fix, and metacity

  • 40 sec: Includes previous with new module-init-tools

  • 56 sec: Jaunty

  • 61 sec: Intrepid with Jaunty Kernel

  • 65 sec: Intrepid

Additional Charts

  • 30 sec: HP Mini 1000, SSD, jaunty alpha 6

  • 46 sec: HP Mini 1000, HDD, jaunty alpha 6

Plans for Karmic (9.10)

Detailed Changes

DESCRIPTION

Status

Switch to rsyslogd as possible alternative to using syslogd and klogd

Done: Alpha 3

Convert to Upstart where possible to allow for easier customization around boot performance for UNR and OEMs

Leverage Kernel Mode Switching (KMS) as a way to improve the performance of graphics bring up

Done

Switch to metacity-compositing as "Normal" visual effects setting, with compiz as "Extra"

Move to .30+ kernel for fastboot improvements

Done

Goto compiling kernel for i586/i686 arch support

Investigating. Recent testing doesn't show any improvement over current compilation options used.

Apply Xserver performance patches found in Moblin image, if applicable

Deferred from Jaunty. See associated Feature Freeze Exception

Set console font, keymap and utf-8 mode from udev while usplash is running

Deferred from Jaunty. See associated Feature Freeze Exception

Fix the hostname tool so an init script is not needed

Deferred from Jaunty. See associated Feature Freeze Exception

Mode-switches and console changes are known to be expensive, in addition they create the intermediate VTs, so start usplash and X on tty1

Deferred from Jaunty.

Change the nm-applet connecting animation to something that doesn't adversely affect performance

Deferred from Jaunty.

Look at some patches from SuSE that speed up gconf and gnome-settings-daemon

Deferred from Jaunty.

Bootcharts

This section will be updated to show our progress towards maximizing our performance for Karmic on a Dell Mini 9.

Proof of Concept: 8.5 secs

  • This is a pure Upstart-based boot of Xubuntu, and not intended to represent a standard Ubuntu Desktop

These charts come from a Dell Mini 10v with HDD:

Work with Debian

DebianUbuntuSprint - As usual, we are committed to working with the Debian community to provide patches across all the packages in main that would benefit from our work in this arena. With this in mind we will investigate creating a joint Ubuntu-Debian team to look into what can be done.

Win7 Comparison Data

See http://people.canonical.com/~cking//graphs/boot-graphs.html

FoundationsTeam/BootPerformance (last edited 2009-11-26 16:49:47 by 99-156-85-10)