Ubuntu 18.10 Looking At LZ4-Compressed Initramfs Image By Default

[polarathene]

I'm not really familiar with the inner workings of initramfs and the early boot process, but maybe it also affects the boot loader (GRUB etc.), not just the kernel?

Not that I know of, I've been building initrd images with various contents to play with boot times myself, got kernel+initrd+userspace and loader times down to about 1 sec, firmware takes 6-9 secs depending if fast/ultra boot is enabled. I've used GRUB and systemd with different compression types, no problems. I believe the kernel is active first, and probably what takes care of the decompressing of initrd image, so your kernel just needs to have support for the compression format in use(if any).

[jacob]

Not that I know of, I've been building initrd images with various contents to play with boot times myself, got kernel+initrd+userspace and loader times down to about 1 sec, firmware takes 6-9 secs depending if fast/ultra boot is enabled. I've used GRUB and systemd with different compression types, no problems. I believe the kernel is active first, and probably what takes care of the decompressing of initrd image, so your kernel just needs to have support for the compression format in use(if any).

Interesting. I always thought that GRUB (or equivalent) decompressed initramfs in memory and passed that as the root fs to the kernel.

[davidbepo]

nice change, also bzip2 initramfs should be killed with fire

[polarathene]

Interesting. I always thought that GRUB (or equivalent) decompressed initramfs in memory and passed that as the root fs to the kernel.

Don't take my word for it I don't know the process that well myself. Just that the bootloader if there is one takes a kernel, optionally an initrd to do some work and then the kernel remounts the rootfs when initrd is done.

systemd-analyze reports the order of times as firmware,loader,kernel,initrd,userspace. I've used systemd-boot too, no idea if the loader is responsible instead for decompression, I know GRUB does some more advanced things that systemd-boot doesn't support, so maybe that's the case?

For a minimal initrd image I can just make sure it includes the kernel modules to access my disk and filesystem for mounting, once it's done it's thing the actual kernel takes over from there with the kernel params passed to it. If something went wrong initrd is meant to provide a minimal means to access the system afaik.

[pcxmac]

not really sure why this is a big deal for ubuntu, it's not exactly the hardest thing to achieve. Going from xz to lz4 is remarkable, and very much faster. I highly recommenced lz4, not only for decompression, but also because it's multi-core and makes cpio compression SOOO MUCH FASTER. It's a win win, peeps on gentoo have probably been rocking this one for a while, even if the genkernel script was dated for a while.

[Vistaus]

ikey_solus Since Solus is so fast for me (and always has been in the past 1.5 years :P), I wonder: what is Solus using here, also LZ4?

[nils_]

Interesting. I always thought that GRUB (or equivalent) decompressed initramfs in memory and passed that as the root fs to the kernel.

The decompression happens in the kernel, the boot loader only loads the file into RAM and passes the address to the kernel. I think this is a pretty complete explanation of the boot process:

https://0xax.gitbooks.io/linux-insides/content/Booting/

[jacob]

The decompression happens in the kernel, the boot loader only loads the file into RAM and passes the address to the kernel. I think this is a pretty complete explanation of the boot process:
https://0xax.gitbooks.io/linux-insides/content/Booting/

That's an interesting writeup, thank you for sharing. I wonder though if there are any substantial differences on other CPU architectures.

[Faalagorn]

I was fiddling with initramfs compression to experiment with lowering already extremely boot times on my Arch desktop with a cheap M2 SSD (samsung SAMSUNG MZNTE256)some time ago, here are the results – basically LZ4 was constantly being faster than no compression at all (and faster than the default BZIP2 or XZ compression, both of which resulted in a way smaller file, but a bit longer boot times), though the changes were minuscule. It was solely due to smaller image size with fast enough decompression speed just as Guest said:

Compression still saves you some time, unless you have nvme. LZ4 has decent compression and near on the fly speeds (1-2GB/s on desktop) so there isn't really an argument not to use it on ssd.

Even if your SSD does 500MB/s reads, image is rather large (no idea about ubuntu, upwards of 50MB all things considered)? My efistub image with initramfs is ~20MB big when compressed with lz4, most of it is nvidia module which gets loaded in initramfs though (kernel itself is 4MB). Gains are pretty small though.

By the way, LZ4 in kernel uses default "lzop" command, which by default doesn't use highest compression level. I wonder if "lzop -9" would change compression ratio for better (decompression speeds are the same, compression is somewhat slower).
Edit: Just grepped source code, it does now.

AFAIK, lzop and lz4 are two different tools, the smallest being indeed -9 for lzop, but -16 for lz4, although the changes over 9 are really small. When I was testing lz4 compression, then indeed, the decompression speed was the same, although the compression of initramfs was noticeably smaller for shaving that couple ms of boot time, although it's only being done on some system updates.

What matters for initramfs compression is combination for a hard drive speed (small file can be processed quickly) and compression speed/CPU speed (assuming the CPU can handle the operation on time, then it's solely the decompression speed time of the algorithm) and in some cases there's of course space issues – IMO lz4 fits that need fine, although there's also lizard that should perform even better than lz4 in terms of compression level @ the same or slightly lower/faster decompression speed (depending on parameters used) and slightly slower, but with better compression zstd, as other mentioned.