Proposed F19 Feature: Dracut HostOnly

[Lennart Poettering]

On Tue, 29.01.13 14:06, Chris Murphy (lists at colorremedies.com) 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 at 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 at f18v ~]# systemd-analyze
> Startup finished in 1892ms (kernel) + 769ms (initrd) + 6086ms (userspace) = 8749ms
> 
> 
> -------Same test, different CPU, HDD:
> 
> Stock:
> 
> [root at f18s boot]# systemd-analyze
> Startup finished in 1180ms (kernel) + 3538ms (initramfs) + 20934ms (userspace) = 25653ms
> 
> host-only initramfs:
> 
> [root at 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.