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. > > 7. 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
