I played around some more. Now I'm back down to 45 seconds by reducing the amount of files I try to read. The libraries needed by mysql, postfix, apache are no longer included, I only try to read ahead the files for gdm. Not for X though - stracing X with the radeon driver made me stare at a black screen...

New Chart.

Generating proper readahead list files is apparently a difficult job. You need to optimize this for the critical path. I believe that manual optimization is the best here, unless you have a cheap way of logging such things.

Here is a Chart with the results of using readahead on my system (47k image)

I also increased the detail level of the chart.

The bad news: Using readahead actually made my bootup slower.

And not just a little bit slower, but a lot. gdm login used to be started after around 30 seconds before, now it is at 57 seconds. That is factor 2!

I'm not sure why, I need to investigate what actually got into my readahead file lists... My whole MySQL databases? All my fonts? ;-)

I tried for a while to find "readahead" listings for Debian or Ubuntu. If you have some, please send me an email where to get them.

I've also written a small app to do better readahead. Current readahead scripts I've seen (from gentoo) use cat to read a file and feed the information into readahead via command line.

I have modified the original "readahead" (apparently from kernel sources) to be able of reading file listings: readahead-list.c.

The file is mmapped, then scanned for newlines. Lines with more than 1024 chars are ignored, but I don't need an alloc this way, which I like.

I'd like to build this with diet libc, but it's lacking the "readahead" function. Maybe the next version will use ioctl or whatever to do this...

Oh, and I have not yet tested it... ;-)

The boot-chart madess is going around. Be warned, this is almost as bad as the "somethingfunny test" madnesses reaching blogs from time to time.

Well, I was infected, too. I ran boot-chart to see how well my hacked together "minit"-based system does.

Be warned, boot-chart is an ugly hack. Don't look to closely at what its boot script does. It basically runs "top -b > logfile". This sucks. Because top is quite different from distribution to distribution. On my system, it doesn't include the PPID information that bootchart uses. Why didn't they do things just right and get exactly the information they want from /proc themselves? Parsing top output is not that much easier (especially since it varies...)

That is the reason why processes, for example the apache stuff, are not grouped in this chart - my top output doesn't include the needed info.

Here are my resuls. Full chart also available. This is a Thinkpad A31p with a P4M 1.8 GHz (no Centrino).

30 seconds till gdm is ready, that is okay. Sure, things could be faster.

Note that my system is not tuned at all. In fact I'm even running hotplug twice: once it is run by rcS (where I use the unmodified Debian rcS) and once by my init system (because I want it included in my normal process so it's run without special handling on hibernate resume)

Using a preloader would probably help a lot, but I'm really eager to get the xserver, cupsd and gdm tuning results from Ubuntu... ;-)

Please don't flood me with questions about "enit" and "enitdir". The first is just a slight - experimental - modification of "minit", and "enitdir" is a tool I once posted to the minit list. It basically monitors a directory and starts all services there with minit. When a service disappears it is stopped again. I use this to switch to a "suspend" runlevel: I shut down mysql, apache etc. before going into hibernate to conserve memory (and thus my suspend is faster) "enitdir" doesn't appear in the primary chart - it is considered idle, since it uses almost no CPU (only writing a couple of chars to a socket and scanning one dir, then using the kernel dnotify interface and going to sleep) A tiny app - less than 6k, statically linked, 28k resident size in memory 0:00.00 CPU time according to top. ;-)