Fedora 10 - Boot Analysis

Harald Hoyer harald at redhat.com
Mon Dec 15 14:47:32 UTC 2008


A brief Fedora 10 boot analysis.

Hardware: Asus EeePC 901 with a flash disk.

Time taken from entering the encrypted root disk password until the password can 
be entered (after pressing return in gdm). The 10 second wait in nash is ignored 
here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).

Default Live CD Installation:  39s (bootchart 

After installing readahead and running one collection boot process: 36s 
(bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)

At this point, I recognized that all processes (NetworkManager and newaliases), 
which call a fsync(), let the boot process wait until all data is written to 
disk. This is the same effect as the firefox sqlite fsync bug 

Mounting the root filessystem with relatime and turning off ordered data writing 
for the journal with

# tune2fs -o journal_data_writeback /dev/root

improved the situation (even though data might be old on the disk after a crash, 
but ext3 does not force the disk to empty the write cache anyway).

Turning off setroubleshoot and fixing 
https://bugzilla.redhat.com/show_bug.cgi?id=476023 and 
https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart 

Turning off bootchart: 30s

So all in all we have nearly accomplished the 30 Second Startup Feature 

To reach the 20 Second Startup Feature 
http://fedoraproject.org/wiki/Features/20SecondStartup, we really have to tackle 
setroubleshootd. Also we might start to move basic services to upstart and start 
them in parallel (bootchart with some services moved 
Parallel booting will show now benefits with readahead and a small amount of 
active services, but the more services are turned on, the more you benefit with 
a parallel boot setup. Moving more basic modules to be compiled in the kernel 
also would gain some seconds. Speaking about modules, I ported Jakubs modprobe 
patch to the recent 3.6pre1 module-init-tools version. Though it nearly halves 
I/O, it would only safe us a fraction of a second here (not recognizable).

In the end, we also have to extend our view to things that happen after the user 
logs in (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-full.png) 
and do an extended analysis. Work is also in progress by Gnome developer Behdad 
Esfahbod http://mces.blogspot.com/2008/12/improving-login-time-part-3.html.

More information about the fedora-devel-list mailing list