sorry for the lag,
On Wed, 2004-12-01 at 03:59 +0100, Ziga Mahkovec wrote:
On Sun, 2004-11-28 at 20:49 -0500, David Zeuthen wrote:
> So, I've looked a bit more into the booting process and how to optimize
> The results are pretty good I think, here is the general time
> with a wallclock
> 00: exit grub; start booting the kernel
> 04: kernel prints audit()
> 11: initrd is mounted; Red Hat nash visible
> mount / ro (normal initrd procedure)
> 13: start bootchart logging; start readahead of approx 193MB files
> sleep until readahead is complete
> 24: readahead done; now
> create /dev and modprobe (in background)
> mount / rw, enable swap
> start xfs
> startx as user davidz in background
> start messagebus
> start hald
> start acpid
> start NetworkManager
Do you have an idea of how much kudzu, cups and syslogd would add to
these times? rhgb too probably, or would it make sense to dump it
I think that cups and syslogd are mostly harmless - for capturing the
readahead files from my modified kernel I had syslogd log dump to /tmp
which I mounted as tmpfs. syslogd should probably start in before gdm,
but cupsd can certainly be started later (ideally it should be started
kudzu is a bit more difficult as it brings up dialogs - I think Bill
agrees (see the thread on fedora-desktop-list that I linked to in my
original mail) that hardware configuration should be handled in the
desktop GUI anyway.
> 7. A number of things was started in parallel - I found that
> readahead while running modprobe wasn't helping anything; in fact
> it contributed negatively to performance (a bit to my surprise, I
> guess because the kernel was busy).
You think it might make sense to try running readahead in background,
but after the modules are loaded? Especially if the readahead list
could somehow coincide with the order of services started, to further
Or is readahead best left running alone?
Not sure; the big boost really comes from reordering the files on the
filesystem - running readahead (which takes 11 seconds) only gives me a
usable desktop four seconds earlier. I'm pretty sure no other process
should do any disk IO when readahead is running as that will almost
certainly incur seek penalties.
> So, I think these numbers are good and there's still some
> improvement; e.g. it takes ten seconds from grub to when the initrd is
> mounted - surely the kernel can boot faster? It's after all 25% of the
> time spent from grub until I have usable desktop.
I did some experiments with bootchart logging in the initrd phase.
Packed the initrd image with bash, ps and a bunch of libraries and
started logging early in the nash script... only to find out that the
whole phase flies by in less than a second :)
Yeah, I found that too.
I would like to visualize the kernel boot though. But I'd need
on what kind of data to collect, and how.
I think some embedded systems (think DVD players) use patches to boot
the kernel faster - I wonder what the status of adding them to mainline
> Thanks a lot to Ziga Mahkovec for the bootchart software -
> very useful.
BTW, I've had loads of fun with SVG lately, so you might want to try
regenerating these charts. Makes them scalable and about 15x smaller in
file size. Have a look at the SVG samples (rsvg does a pretty good