5 sec boot

Mitch Bradley wmb at laptop.org
Fri Oct 3 13:34:58 EDT 2008


>
> Could somebody explain me whether [the 5 second boot] results are applicable to the 
> XO, and how far are we from it, please?
>
>   

Ticket http://dev.laptop.org/ticket/4349 details my and codyl's 
experiments with speeding up boot.

Between the two of us, we managed to shave off 23 seconds.  We used some 
techiques similar to those in the 5-second paper - eliminating udev, 
paring down initscripts.

The techniques that we used haven't been deployed for several reasons:

a) Some people argue that we shouldn't bother to speed up boot, because 
suspend/resume optimization is more important.  (I agree that S/R is 
more important, but I wish that we could do both.)

b) OLPC's software team is tiny relative to the number of laptops that 
we are shipping.  As a result, we can't diverge from Fedora as much as 
would be appropriate (considering the extent to which XO diverges from 
Fedora's target "generic PC").  We just don't have enough people to 
maintain a heavily-customized startup sequence.  (Some have suggested 
that parallelized init strategies, as some distros are starting to 
adopt, is the solution.  I disagree, based on my understanding of how 
the XO hardware works - there is just not much parallelism possible on 
this hardware.)

As jg points out, there is another 14+ seconds available by changing the 
NAND layout. We could get 7 seconds just by partitioning the NAND, 
without changing filesystems (support for this has been in OFW since 
last Christmas).  Switching to UBIFS would gain another 7 seconds.

Combining all the techniques mentioned in this message would get us down 
to perhaps 30 seconds (power on to console login prompt), but there is 
still the issue of X and Sugar startup time.  To get close to the 5 
second number, we would have to adopt some of the additional techniques 
cited in the paper, such as non-modular/no-initrd/async-init kernel, 
deeply-pared initscript, pre-computed XKB configuration, etc.

And then there is the problem of Python startup time.  We have some 
techniques to help that, but it's still a factor.




More information about the Devel mailing list