Boot Performance Targets for Karmic and +1

[Scott Kitterman]

On Tue, 09 Jun 2009 10:24:28 +0100 Scott James Remnant 
<scott at canonical.com> wrote:
>On Tue, 2009-06-09 at 10:40 +0200, Martin Pitt wrote:
>
>> I think there's one important piece missing here: readahead. Right now
>> we do that in a single big chunk, right after initramfs. On my box it
>> takes about 7 seconds; I guess it's faster on your's, but it would
>> still not even closely fit into the 2s + 2s second budget.
>> 
>Where we do readahead actually depends on whether we're on a HDD or an
>SSD.  On an SSD we run readahead in the background alongside everything
>else, and there is no performance penalty for doing so.
>
>On an HDD, obviously this isn't quite so easy.
>
>> Can we sensibly split readahead to read the X bits first, and then
>> everything else in a second block? This might not be relevant with
>> sreadahead and SSDs (since stuff gets read in usage order), but is a
>> problem on rotary disks (where readahead reads them in disk block
>> order).
>> 
>Firstly I figure we'll actually end up actually making sreadahead have
>an HDD mode, rather than retrofitting this stuff into readahead itself.
>
>My current thought is to have a "boot priority" list, that includes
>everything udev runs and is needed to start X which we run on the
>read-only root filesystem.
>
>We might then have other per-filesystem lists which we run as we mount
>them (these can run safely in parallel with the root list because
>they're on different drives).
>
>And finally we'd have a second-stage root list which runs once X is
>started.
>
>Obviously these all need to be in series with the boot sequence.  This
>is actually another case where we might want a splash screen, since it
>could take a few seconds.
>

I'm just starting to learn about this area. As we (very briefly) discussed at UDS, I'm 
interested in trying to extend this work to improve boot performance for Kubuntu.

Is this something that can be changed on a per flavor basis?  

Scott K