Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

On Mon, 2009-03-02 at 10:27 -0800, Arjan van de Ven wrote:
> On Mon, 2 Mar 2009 17:29:57 +0100
> Kay Sievers <kay.sievers@xxxxxxxx> wrote:
> 
> > On Mon, Mar 2, 2009 at 17:20, Arjan van de Ven <arjan@xxxxxxxxxxxxx>
> > wrote:

[...]

> > > I would strongly suggest that you turn on the async function calls
> > > and look at the boot graph of the resulting kernel boot... if you
> > > send that to me I can also take a look and make suggestions....
> > 
> > The "fastboot" kernel commandline option was used, as mentioned in the
> > mail. Is there anything else?
> 
> there is some sata level enabling needed depending on the system;
> I'd love to see the bootgraph (scripts/bootgraph.pl) for the boot;
> that shows exactly what happens when and for how long.
> 
Well, this was certainly an eye opener. I can only say thanks for
pointing out bootgraph!

You asked for one graph, but Rusty suggested that I compare insmod and
modprobe (though in another context), so I did more than one.

The (somewhat messy) combined result from booting four initramfs images
with slightly different setups is attached. 

All of them install the 94 modules needed on the test system and all use
2.6.29-rc6 configured like a Ubuntu 8.10 generic kernel. The module
mutex minimizing patch is added, but not the stop_machine patch. (The
merge failed due to my own patches. I need to have a look at it again.)
Fastboot is enabled.

bootgraph.pl was tweaked to, among other things, not stop until when a
dummy module was inserted. This happened after udev had settled and just
before chaining to the file system on the hard drive.

1: (top row, light blue). This installed modules using udev 124 and
modprobe 3.3pre11 that are shipped with Ubuntu 8.10.

2: (second row, light green). This installed modules using the latest
versions of udev (139) and modprobe (3.7pre6) from the git repos.

3: (third row, light yellow). This used a multithreaded insmod. It
employs a very simple method to spawn child processes, so it looks
different from the others and had to be compressed vertically to fit.
(And four processes hang until all initcalls are done and the parent
process dies, so it's kind of buggy too.)

4: (bottom row, pink). This is the megamodule, only added out of
curiosity. It really is multithreaded, but it doesn't use
do_one_initcall() so you can't see anything.

Attachment: bootgraph.svg
Description: image/svg