Summary

It seems that a 5 second boot demonstrated at the 2008 Linux Plumber's Conference has really captured the attention of Linux users. Despite the specialized configuration demonstrated by Intel, a general purpose distribution ought to be able to boot to a useable desktop much faster then the current 30-60 seconds.

This specification focuses on the components of the kernel and support applications that are active during the startup process.

Release Note

Rationale

If a system could boot sufficiently fast, then why bother with suspend/resume or hibernate ?

Use Cases

This seems obvious to me. The faster your system boots, then the sooner it is usable. Furthermore, if one could use a fast boot to avoid suspend/resume, then one could also enjoy the highest possible power conservation setting, i.e., the system is turned off.

Assumptions

Design

Implementation

Kernel Config Changes

Migration

Test/Demo Plan

Unresolved issues

UDS agenda and discussion

Intro

Discussion

Solutions

Action Items

--- end of first half of session ---

Readahead

Action items

Next topic: Perform device probing in parallel on different busses

Next topic: "Stop the legal fiction of late binding in linux-restricted-modules"

Discussion: can we use the kernel audit hooks to save a stream that can be reassembled into a boot description with time stamps?

initramfs - at the top, see whether the root fs exists, then use it Action items:

End of session

=========================================== Foundations Team - Boot Performance ===========================================

Reference platform for boot chart is:

Suggested Improvements to boot time: - udev and hal walk the tree of devices, this should only be done once - X takes 7-8 seconds to start (Desktop Team) - CUPS doesn't need to be loaded until the user needs to print for the first time. - Many of shell scripts run at every boot (major effect because they are not portable to other parts of the boot, not flexible enough). Proposed solution is to have a mountall binary that works though udev. - Setting the keyboard, fonts, can be done through udev. We currently don't do this today. When you set those things in the kernel, you do this in the first tty. The other 7 will inherent these. - usplash (creates tty8) and kills the work that was done previously.

-init-ng independent daemon - (easier to say apache depends bind) more modular, starts all services simultaneously.

-launchd (Apple) - inet superserver, starts and listens on ports and paths. all services are started when you first talk to them. Drawbacks on launchd: changing hardware. Proposed solution: We can do something similar though dbus, with upstart service activation.


CategorySpec

KernelTeam/Specs/BootPerformance (last edited 2008-12-29 22:17:52 by nigelenki)