Boot charting

[Tristan Wibberley]

Phillip Susi wrote:
> I have been studying my boot charts and it looks like readahead-list
> needs improved.  One problem I notice is that after readahead-list
> completes, there is still a fair amount of IO done.  It looks like it is
> being done mostly by Xorg and nmbd.  Whatever files these are accessing
> should be added to the readahead-list.  Is there a way to have bootchart
> log which files are being read?
> 
> The other problem seems to be that readahead-list is only managing to
> pull 25% of my disk's maximum sustained throughput.  According to the
> image it peaks at 25 MB/s, but my raid array is capable of sustaining
> nearly 100 MB/s.  I believe this is because the files that are being
> read are scattered all around the disk, so there are a lot of seeks
> involved which slow down the throughput.

Or it could be single-threaded, so a read is issued, then completes,
such that the head is in the wrong place for the next read, which is
subsequently issued, leaving the head in the wrong place for the next,
etc. If so, then using asynchronous mechanisms could provide a
performance boost (the speed I'm getting for readahead-list seems far to
small for the normal level of fragmentation I expect to have). If it
already *is* asynchronous then playing with the kernel tunables before
running readahead and resetting them afterwards could help by extending
the I/O queue length and reducing the fairness to allow the reads to be
ordered better.


> I searched and searched and it seems that the Linux community still
> feels ( wrongly imho ) that there is no need to defragment hard disks.

> As an alternative, I thought that maybe these files could be packed into
> a cramfs image that is mounted from the initramfs and overlaid on top of
> the original filesystem with unionfs.  I tried messing around with this
> a bit but for some reason after the run-init switches to the root
> filesystem, the cramfs is no longer accssible so the kernel panics.
> 
> Maybe someone with more experience with unionfs could take a crack?

I don't have more experience (none whatsoever), but that looks really
interesting. Could you send me details of what you did, and any diffs
against stock scripts? I'd like to see this and have a play.


The biggest problems I see during boot (before gdmgreeter goes quiet)
are modprobe in the initramfs and elsewhere, hwclock, hald-probe-volu
(whatever that is short for), Xorg and gdmgreeter startup, or the fact
that things wait for others where they shouldn't need to. In most cases
they *do* need to but ought not - that requires some big surgery to
packages to fix it properly which I guess is certainly *not* going to
happen for dapper.

-- 
Tristan Wibberley