Part I: Linux Boot Optimization: Introduction & Implementation thought

... somehow I was thinking about boot processes and its time and payloads on Windows and Linux and compare their "boot time" and the time that the OS ready to respond to a request from a network, console or so on.Thanks to David Zeuthen & Owen Taylor and after of all tests there were so many usefull results which I would like to brief them.

Currently, the time to boot the Linux desktop from the point where the power switch is turned on, to the point where the user can start doing work is roughly two minutes.
During that time, there are basically three resources being used: the hard disk, the CPU, and the natural latency of external systems - the time it takes a monitor to respond to a DDC probe, the time it takes for the system to get an IP via DCHP, and so forth.
Ideally, system boot would involve a 3-4 second sequential read of around 100 megabytes of data from the hard disk, CPU utilization would be parallelized with that, and all queries on external systems would be asynchronous ... startup continues and once the external system responds, the system state is updated. Plausibly the user could start work under 10 seconds on this ideal system.
The challenge is to create a single poster showing graphically what is going on during the boot, what is the utilization of resources, how the current boot differs from the ideal world of 100% disk and CPU utilization, and thus, where are the opportunities for optimization.

So had a brief look at shortening startup/login time and tried

disabling rhgb in favor of starting gdm early. It looks pretty

promising; here are some wall-clock numbers from two runs of each

configuration:



                    |   gdm_early  |   rhgb+gdm   |

----------------------+------+-------+-------+------+

GRUB timeout          | 0:00 | 0:00  |  0:00 | 0:00 |

Starting udev         | 0:13 | 0:13  |  0:13 | 0:14 |

HW init done          | 0:25 | 0:25  |  0:26 | 0:26 |

rhgb visible          |  N/A |  N/A  |  0:36 | 0:35 |

gdm login visible     | 0:43 | 0:44  |  1:25 | 1:26 |

gdm login entered     | 0:52 | 0:52  |  1:31 | 1:32 |

GNOME banner visible  | 1:13 | 1:14  |  1:40 | 1:41 |

Nautilus Background   | 1:33 | 1:32  |  1:51 | 1:52 |

Panel visible         | 1:43 | 1:43  |  2:02 | 2:02 |

HD activity off       | 1:59 | 1:56  |  2:13 | 2:14 |



The milestones should be pretty self evident. This is on a stock FC3

system running on a IBM T41 1.6GHz (running on AC power), 512MB RAM

without any services manually disabled.



In addition to starting gdm early, the modifications also start up a few

services, D-BUS, HAL and NetworkManager, that is critical to the GNOME

desktop.



Some random thoughts/observations:



- We get the gdm window 40 secs faster



- The 12 secs from "Starting udev" to "HW init done" can be mostly

shaved away/run in parallel



- Kernel bootstrap time (13 secs) can probably be much shorter

(that's what some kernel guys say anyway)



- With this hack we shave twenty secs of the booting time (e.g. from

GRUB until you can use your PC) but booting still feels much quicker

because of the interaction with gdm in the middle (YMMV; e.g. placebo

effect etc.)



- rhgb+gdm spawns an X server each which is sort of stupid and unsafe

(or so some Xorg guys tell me). This solution, per design, avoids

doing that



- we don't get the kudzu screen nor the fsck screens or any other

console interactions. However, IMHO, such screens are not good UI

in the first place - we should instead have GUI replacemnts that

possibly notifies you when you log into the desktop session (stuff

like NetworkManager and HAL alleviates such problems for networking

and storage devices)



- we don't get service startup notification, but, uhmm, is it really

useful learning that the "Console Mouse Service" or "Printing Sub-

system" have started? Instead, this stuff could just be put in gdm



- it could be interesting to make /sbin/init own a D-BUS service that

gdm and other stuff can query and interact with. Could also be fun

to completely replace it with something a'la the SystemServices

prototype that Seth did last year; links



http://www.osnews.com/story.php?news_id=4711

http://www.gnome.org/~seth/blog/2003/Sep/27



- Could be interesting to instrument the kernel with some pagefault

counters etc. and attempt do more readahead on e.g. the GNOME libs

(both Windows XP and Mac OS X does all that; I think we do too but

I've been told it can be improved)



So, anyway, I think it could be interesting to discuss starting gdm

instead of rhgb. If you want to try out my crude hack, grab the file

here



http://people.redhat.com/davidz/newinit.sh



put it in on your system as /newinit.sh, chmod a+x it and change this

line /etc/inittab



si::sysinit:/etc/rc.d/rc.sysinit



to these two lines



#si::sysinit:/etc/rc.d/rc.sysinit

si::sysinit:/newinit.sh



and you should be set to go! If it breaks you get to keep both pieces;

e.g. try this at your own risk [1].