BootPerformance
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:
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.
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.
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.
Suspend/Resume is Not the Answer - Yes, a fast suspend/resume cycle is extremely useful, not to mention very cool , 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.
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!).
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. 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
- This is a pure Upstart-based boot of Xubuntu, and not intended to represent a standard Ubuntu Desktop
Dell Mini 10v with HDD
sam-karmic-20090727-5.png 38s without Ubuntu One
sam-karmic-20090727-4.png 45s Karmic 2009-07-27
sam-karmic-20090727-3.png 43s Karmic Alpha 3 with sreadahead instead
- Even though it's not HDD-optimised, it's still a win!
sam-karmic-20090727-2.png 48s Karmic Alpha 3 after readahead profiling
sam-karmic-20090727-1.png 47.5s Karmic Alpha 3
UbuntuOne adds lots of time
sam-karmic-20090717-2.png 40s Karmic Alpha 2 after readahead profiling
- readahead always makes a small difference
sam-karmic-20090717-1.png 41s Karmic Alpha 2
- Karmic already showing a bit of improvement
sam-jaunty-20090717-4.png 45s Jaunty with updates after readahead profiling
sam-jaunty-20090717-3.png 45s Jaunty with updates
sam-jaunty-20090717-2.png 43s Jaunty release after readahead profiling
- so even our release readahead wasn't as good as re-profiling
sam-jaunty-20090717-1.png 45s Jaunty release
Dell Mini 10v with SDD
max-karmic-20090727-5.png 27.5s without Ubuntu One
max-karmic-20090727-4.png 31s Karmic 2009-07-27
max-karmic-20090727-3.png 31.5s Karmic Alpha 3 with sreadahead instead
max-karmic-20090727-2.png 32.5s Karmic Alpha 3 after readahead profiling
max-karmic-20090727-1.png 32.5s Karmic Alpha 3
UbuntuOne adds lots of time
max-karmic-20090724-3.png 29s Karmic Alpha 2 with sreadahead
- not quite a real test, since it involved updating the kernel and upstart, but...
max-karmic-20090724-2.png 30.5s Karmic Alpha 2 after readahead profiling
- actually makes it slower
max-karmic-20090724-1.png 29.5s Karmic Alpha 2
max-jaunty-20090724-6.png 31.5s Jaunty with updates and sreadahead
max-jaunty-20090724-5.png 31.5s Jaunty with updates after readahead profiling
max-jaunty-20090724-4.png 31.5s Jaunty with updates
max-jaunty-20090724-3.png 30s Jaunty release with sreadahead
- sreadahead makes a slight improvement again
max-jaunty-20090724-2.png 31s Jaunty release after readahead profiling
max-jaunty-20090724-1.png 32.5s Jaunty release
Dell Mini 9
- 2009-09-18
dellmini9-karmic-20090918-1.png 28s to fully functional desktop
Ignore the red line as this is not when xsplash terminates...only pauses here.
- system is usable and considered "booted" when 'xsplash' terminates.
- Karmic Beta+ (has additional updates post Beta release)
login-karmic-20091016.png 19s to login
autologin-karmic-20091016.png 28s to fully functional desktop
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:
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)