Ubuntu Moving Ahead With Compressing Their Kernel Image Using LZ4

[phoronix]

Phoronix: Ubuntu Moving Ahead With Compressing Their Kernel Image Using LZ4

Ubuntu will begin compressing its kernel image / initramfs using the LZ4 compression scheme to improve the experience around their installer and for cloud/core/classic devices. There is some concern over the performance to which they may do additional tweaking...

http://www.phoronix.com/scan.php?pag...buntu-Go-Ahead

[Danny3]

This is great news!
For me even having the kernel image file size increased two or three times it's ok when there's the advantage of having faster boot time.
I can barely wait to test it on my laptop.

[varikonniemi]

What is the decompression speed difference on for instance a librem5 powered device?

[skeevy420]

This is great news!
For me even having the kernel image file size increased two or three times it's ok when there's the advantage of having faster boot time.
I can barely wait to test it on my laptop.

I'm the opposite. It takes 15 seconds just for my workstation to finish POST to even to be able to hit F12 and access the BIOS, from there another 3 seconds for GRUB to boot up, 5 seconds there unless I hit enter, and finally we're to the kernel decompress part...after all of that I could care less that xz -9 -e takes up to ~5 seconds to decompress...and from there it still takes 30 or 40 seconds until my desktop is 100% usable without any risk of IO boot lag.

Since a power on cycle takes me around a minute, kernel decompression speeds just seem very irrelevant.

[Danny3]

I'm the opposite. It takes 15 seconds just for my workstation to finish POST to even to be able to hit F12 and access the BIOS, from there another 3 seconds for GRUB to boot up, 5 seconds there unless I hit enter, and finally we're to the kernel decompress part...after all of that I could care less that xz -9 -e takes up to ~5 seconds to decompress...and from there it still takes 30 or 40 seconds until my desktop is 100% usable without any risk of IO boot lag.

Since a power on cycle takes me around a minute, kernel decompression speeds just seem very irrelevant.

I understand what you mean, but not everyone is using the same hardware.
Some of us that are luckier may have motherboards with better POST time and some might use a GRUB alternative like the systemd bootloader that I don't remember the name.

I use a Ubuntu based distro also on my pendrive with persistent storage so I can plug it and run it on other computers which might have better POST time than mine, so I find it nice that the distro improves the boot time as much as possible on its side of things.

[skeevy420]

I understand what you mean, but not everyone is using the same hardware.
Some of us that are luckier may have motherboards with better POST time and some might use a GRUB alternative like the systemd bootloader that I don't remember the name.

I use a Ubuntu based distro also on my pendrive with persistent storage so I can plug it and run it on other computers which might have better POST time than mine, so I find it nice that the distro improves the boot time as much as possible on its side of things.

Which is why I liked your post even though we have different situations and needs. Faster anything helps, don't get me wrong, but it can also be a moot effort on enterprise grade workstations and servers due to how long their POST processes can be. My POST is as fast as a rabbit compared to some workstations and it's slow as a turtle when compared to your laptop.

It's systemd-boot. You were "that" close.

I can cut my boot time by maybe 10 seconds but that makes it a real pain in the ass to access the GRUB menu to boot up Windows or a recovery kernel. Since I only ever reboot to deal with certain package upgrades (kernel, systemd, kde, etc) or to switch the OS, making that part of the boot up a tiny bit faster isn't something I actually want to do since it makes it harder to use my computer.

[discordian]

What happened to zstd support for kernel and initramfs? Seems to me the perfect fit, very small (but not smallest) and very fast (but not fastest).

There is a patchset I am using personally, no clue why this is not merged yet: https://lwn.net/Articles/771364/

[eva2000]

yeah i thought zstd was planned ?

[ms178]

I was also thinking that zstd would get this job. Why aren't they pushing the zstd patchset into a mergable state then?

[LoveRPi]

In modern era of SSD and eMMC based drives, lz4 is optimally suited. It's the only compression and decompression method that can saturate these devices. zstd/gzip/lzo/lzma/xz are all inferior on modern hardware.