[PATCH] Simple parallellized boot sequence (and a plea for LSB complience)

[a-aa]

Petter Reinholdtsen wrote:

>[Petter Reinholdtsen]
>  
>
>>Recently, I have been investigating how to speed up the boot process
>>in Debian, and during this work, I found a simple way to change
>>/etc/init.d/rc to run all init.d scripts with the same sequence
>>number in parallell.
>>    
>>
>
>I continued on this approach a bit, using the LTSP thin client boot as
>my test case, and using insserv to reorganize the symlinks in
>/etc/rcS.d/ and /etc/rc2.d/ to match the dependency order I inserted
>into the init.d scripts based on testing and experience.  Patch below.
>
>The current patch take the level of concurrency as an option, and I
>tested with several values (1,2,4,8).  These are the raw numbers, in
>qemu seconds (which do not match wall clock seconds :).
>
>     rcS  rc2  total    %speedup
> 1  2616  204   2820        0%
> 2  4752  213   4965      -76%
> 4  1670  199   1869       33%
> 8   877  193   1070       62%
>
>The speedup percent is relative to the single subprocess case.
>
>So if we can get dependency information into all the init.d scripts,
>we should be able to speed up the boot process quite a bit by just
>modifying the script order and running all script with the same order
>value at the same time.
>
>This is my current patch.  In addition to adding LSB headers, I change
>rc and rcS to
>
> - write time spend in each boot script to /tmp/bootlog
> - always use a startup() function to run subscripts
> - run at most $CONCURRENCY subprocesses in parallel.
>  
>
This seems like a fairly simple aproach, and simple is always good.  The
way I've been toying with speeding up boot lately has been a readahead
daemon.  It's fairly rough, and not tested or tweaked much, but the code
is in https://hollowtube.mine.nu/svn/readaheadDaemon/trunk/ , if you
wanna try to combine that into your data to see if it'll help. 

Chances are you wont see that in qemu though, as io would be cached
(which will also screw with your boot results, although in my experience
chances are gains are higher on a real system).


readaheadDaemon consists of two programs, readahead.makedb, using
inotify in kernel 2.6.13 to monitor file access and making a database
out of it, and readahead.scanner, that does the actual readahead on very
low priority.  I wouldn't post it unless I thought you would be able to
figure it out, as my example initscripts are .. lacking a bit ;)