Boot Performance Targets for Karmic and +1
Scott James Remnant
scott at canonical.com
Mon Jun 8 15:07:09 UTC 2009
I've crossposted this first mail of the cycle to the ubuntu-devel and
ubuntu-devel-discuss mailing lists. If you're interested in Boot
Performance work in Ubuntu, you may want to subscribe to the ubuntu-boot
mailing list since that's where I and others working on this will send
For those that missed it, I've put a copy of my UDS presentation at the
My presentation style doesn't lend itself well to reading the slides
themselves back afterwards, but the Notes to the slides should help you
understand what I was talking about.
In summary, our target boot speed for Ubuntu 10.04 (karmic+1) is 10s.
For karmic itself, we'll work towards this but expect to be somewhere
between our current speed and the final target.
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 my own. If you're comparing bootcharts on a different
platform, be sure _not_ to compare the numbers with mine - just the
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 already stated; 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).
In order to reach that target, we need to make some assumptions and we
need to work to a budget.
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
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
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
- 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
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
I've split the boot into a few obvious sections, and given each one a
time budget. To reach the target of 10s, each of these sections needs
to be at or under its 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)
This is for driver loading, filesystem mounting, general busy
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.
These aren't too arbitrary, but are based on what should be possible and
 sharp-eyed readers will know this has just been end-of-lifed; we
have yet to decide whether to change the platform as a result - a
possibility is to use the Dell Mini 10v which should give
near-identical results, but we haven't verified that yet
Scott James Remnant
scott at canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the Ubuntu-devel-discuss