Hey,
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 it.
Great work!
Thanks.
The results are pretty good I think, here is the general time line made 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 completely?
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 on demand).
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.
- A number of things was started in parallel - I found that doing 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 reduce seeking. 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 room for 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 pointers 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 are?
Thanks a lot to Ziga Mahkovec for the bootchart software - it's been 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 job): http://www.klika.si/ziga/bootchart/#Samples
Awesome.
Cheers, David