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 future mails.
For those that missed it, I've put a copy of my UDS presentation at the following URL: http://people.ubuntu.com/~scott/boot-performance/Fast%20Boot.odp 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[0], 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 shape. 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 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. 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) 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. These aren't too arbitrary, but are based on what should be possible and achievable. Scott [0] 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 sc...@canonical.com
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss