BootPerformance

Differences between revisions 60 and 61
Revision 60 as of 2009-11-19 21:42:10
Size: 17185
Editor: pal-174-240
Comment:
Revision 61 as of 2009-11-26 16:49:47
Size: 17088
Editor: 99-156-85-10
Comment: Changed to daily tracking of boot speed and added the link to the data
Deletions are marked like this. Additions are marked like this.
Line 148: Line 148:
With our goal of switching to [[upstart]] in 9.10 met, we can now focus on achieving the '''10sec boot''' milestone we set for Lucid. We will switch to a '''Dell Mini 10v with SSD''' as our reference platform and regularly report results on a weekly basis, starting with Alpha 1. Time and bootchart results for both SSD and HDD storage will be posted. If the kernel slips past it's 2 second allotment, a kernel bootgraph (example:[[attachment:bootgraph.pdf]]) will be included in the results. With our goal of switching to [[upstart]] in 9.10 met, we can now focus on achieving the '''10sec boot''' milestone we set for Lucid. We will switch to a '''Dell Mini 10v with SSD''' as our reference platform and regularly report results on a daily basis. Time and bootchart results for both SSD and HDD storage will be posted. If the kernel slips past it's 2 second allotment, a kernel bootgraph (example:[[attachment:bootgraph.pdf]]) will be included in the results.
Line 165: Line 165:
=== Dell Mini 10v SSD ===
 * Week 6 (Alpha1)
  * Boot Time:
  * Boot Chart:

=== Dell Mini 10v HDD ===
 * Week 6 (Alpha1)
  * Boot Time:
  * Boot Chart:
=== Daily Boot Performance Data ===
http://people.canonical.com/~scott/daily-bootcharts/

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 no 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.

9.04 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.

9.04 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.

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

Plans for Karmic (9.10)

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

Done: Alpha 6

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

Done

Move to .30+ kernel for fastboot improvements

Done

Goto compiling kernel for i586/i686 arch support

Done. No 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

Done. We switched to xsplash

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

Not Needed

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

Not needed

9.10 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

Dell Mini 10v with HDD

Dell Mini 10v with SDD

Dell Mini 9

Plans for Lucid (10.04)

With our goal of switching to upstart in 9.10 met, we can now focus on achieving the 10sec boot milestone we set for Lucid. We will switch to a Dell Mini 10v with SSD as our reference platform and regularly report results on a daily basis. Time and bootchart results for both SSD and HDD storage will be posted. If the kernel slips past it's 2 second allotment, a kernel bootgraph (example:bootgraph.pdf) will be included in the results.

Lucid Blueprints

10.04 Boot Budget

A target like 10s means we need a budget for each major component of the boot sequence:

  • Boot Component

    Budgeted Time

    Comments

    Kernel

    2s

    including initramfs

    Plumbing

    2s

    driver loading, filesystem mounting, core services

    X

    2s

    including gdm

    Desktop

    4s

    everything else

Daily Boot Performance Data

http://people.canonical.com/~scott/daily-bootcharts/

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.

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