Faster Boot in 2.6.19??

Merge window for the next 2.6.19 kernel is already closed by Linus Torvalds by releasing RC1 few days ago. When i saw LWN's Kernel Development Page, i saw an interesting article about the efforts to increase boot time in Linux platform by changing the API driver core, so hopefully when the final version of 2.6.19 is released, we will have a faster system (but don't expect too much as it will still be marked experimental in 2.6.19 and probably will be finished and considered stable on 2.6.20).

Here are the article:

The Linux driver core subsystem continues to evolve at a high rate. The set of patches for 2.6.19 continues this process with a number of improvements - and a number of API changes. This time around, however, the changes appear to be additive, and thus should not break any existing drivers.

Linux boot time is an ongoing sore point - there are few users who wish that their systems would take longer to come up. There are many things which happen during the boot process, and many possible ways of speeding things up. Most of the opportunities for improving boot time lie in user space, but, on the kernel side, probing for devices can take a lot of time. Each device must be located, initialized, and hooked into the system; this process can involve waiting for peripheral processors to boot, firmware loads, and, perhaps, even physical processes like spinning up disks. As a result, much of the kernel time spent bringing up devices is idle time, waiting for the device to do its part.

One obvious idea for improving this process is to probe devices in parallel. That way, when the kernel is waiting for one device to respond, it can be setting up another; the kernel would also be able to make full use of multiprocessor systems. The 2.6.19 device core will, at last, have the ability to operate in this mode. The changes start by adding a flag (multithread_probe) to the device_driver structure. At probe time, if a driver has set that flag, the actual work of setting up the device will be pushed into a separate kernel thread which can run in parallel with all the others. At the end of the initialization process, the kernel waits for all outstanding probe threads to finish before mounting the root filesystem and starting up user space.

On uniprocessor systems, this change leads to a relatively small reduction of bootstrap time. Drivers typically do not yield the processor during the probe process, so there is relatively little opportunity for parallelism, even during times when the kernel has to wait for a bit. On multiprocessor systems, however, the effect can be rather more pronounced - each CPU can be probing devices in parallel with all the others. So this change will be most useful on large systems with lots of attached devices.

At least, it will be useful once it's enabled; this feature is currently marked "experimental" and carries a number of warnings. Even when it is turned on, it only applies to PCI devices. Not all drivers are written with parallel probing in mind, so they may not have the right sort of locking in place. There can be problems with power drain - turning on too many devices simultaneously can cause a high demand for power over a short period of time; if this demand exceeds what the power supply can deliver, the resulting conflagration could slow the boot process considerably. The order of device enumeration is likely to become less deterministic. And so on. Still, this feature, over time, should lead to faster system boots, especially on systems (such as embedded applications) where the mix of hardware is well understood and static.