adventures in booting

[David Zeuthen]

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