On Tue, 29.01.13 14:06, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > Am 29.01.2013 16:55, schrieb Bryn M. Reeves: > > Again, unless you have very different storage controllers this will not break. > > > > I really don't want or need every FC HBA kernel module, firmware bin file or other junk in my laptop initramfs > > "just in case" I happen to swap the disk to a laptop with built-in fibre-channel :-) > > > The proposal not seem to be a significant performance enhancer. > > > Fairly stock Fedora 18, on SSD: > > [root@f18v ~]# systemd-analyze > Startup finished in 2185ms (kernel) + 1493ms (initrd) + 5834ms (userspace) = 9513ms > > After making 91-host-only.conf and running dracut -f. I get a 7.2MB initramfs instead of 31MB. And: > > [root@f18v ~]# systemd-analyze > Startup finished in 1892ms (kernel) + 769ms (initrd) + 6086ms (userspace) = 8749ms > > > -------Same test, different CPU, HDD: > > Stock: > > [root@f18s boot]# systemd-analyze > Startup finished in 1180ms (kernel) + 3538ms (initramfs) + 20934ms (userspace) = 25653ms > > host-only initramfs: > > [root@f18s ~]# systemd-analyze > Startup finished in 1082ms (kernel) + 2914ms (initramfs) + 25410ms (userspace) = 29407ms > > > Curiously, the userspace figure consistently is longer when the > initramfs is smaller. (Now if someone wants to explain how the kernel > has 1/2 the time on a core2duo+HDD, compared to corei7+SSD, I can > accept that offline.) Much of the time is saved in the bootloader, since the initrd imager is now much shorter the boot loader will require muss less time to read it into memory. systemd-analyze won't show you this data (unless you run a git version and use gummiboot as boot loader.) That userspace is slower without initrd is probably because now some jobs that the initrd already did have to be done by userspace instead. Make sure to drop /.readahead before making these tests, and then reboot at least twice (ignoring the first run) before posting any performance data. Otherwise the readahead logic will skew your results. (And 10s boot, that's bad. Do you have LVM in the loop? LVM is the primary reason why our boots are slow. If you try to analyze your boot times it's best to get LVM out of the equation entirely, as that fucks everything up due to its flawed device discovery logic.) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
