On Mon, 2008-12-15 at 15:47 +0100, Harald Hoyer wrote: > http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis > > 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 > http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png) > > 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), Odd, NM isn't intentionally calling fsync() (it's not anywhere in the code), nor does glib do that anywhere that I can find. I can't think of anything that would require an fsync for NM, so I'm interested in finding this and killing it. dan > 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 > http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/. > > 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 > http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png) > > Turning off bootchart: 30s > > So all in all we have nearly accomplished the 30 Second Startup Feature > http://fedoraproject.org/wiki/Features/30SecondStartup. > > 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 > http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble-upstart.png). > 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. > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
