Ubuntu Moving Ahead With Compressing Their Kernel Image Using LZ4

[smitty3268]

According to this page : https://github.com/facebook/zstd

Decompress speed:
lz4: 4220 MB/s
gzip-1: 440 MB/s
zstd-1: 1360 MB/s

So even gzip-1 should be good enough unless you have NVMe drive that can do 1GB/s +

Personally I would rather save the space than getting a fraction of a second increase in speed...

zstd-1 would be optimal though.

Note those numbers were gathered on a Core i9-9900K CPU @ 5.0GHz. A laptop is going to be significantly slower.

[Raka555]

According to this page : https://github.com/facebook/zstd

Decompress speed:
lz4: 4220 MB/s
gzip-1: 440 MB/s
zstd-1: 1360 MB/s

So even gzip-1 should be good enough unless you have NVMe drive that can do 1GB/s +

Personally I would rather save the space than getting a fraction of a second increase in speed...

zstd-1 would be optimal though. (Edit: from candidates in that table)

Edit1:
Lets take a hypothetical image that is 20MB in size:
Compress with zstd-1:
6.93 MB
Compress with lz4:
9.52 MB
Compress with gzip-1:
7.29 MB

Load time:
zstd-1:
5.099 ms
lz4:
2.255 ms
gzip-1:
16.571 ms

Saving 14ms during boot (only on NVMe) feels kind of optimizing the wrong thing ...

Edit2:
Ok so those values are for a i9900k-wara-wara-wara

So lets say my crappy laptop is 10x slower than mentioned machine.(Crappy laptop probably doesn't even have SDD, in which case then (decompress speed/compression ratio) is king like Compartmentalisation rightly pointed out)

Now the load times (assume SSD for crappy laptop so disk io doesn't break the math)
Load time:
zstd-1:
50.09 ms
lz4:
22.55 ms
gzip-1:
160.571 ms

So now it is 138.02 ms faster at boot time. Still not even close to a second ...

[Compartmentalisation]

I've been compressing my kernels with xz for years, it was certainly the smallest option when I picked it then. They're 8MB each with the firmware and drivers baked in - no modules

I use xz on Arch installations too. I don't use the autodetect hook for portability and because it bugged out once so I'll never trust autodetect again. xz keeps the non-autodetect initrd nice and small.

Way to go, Dimitri John Ledkov! I remember you from the Ubuntu mailing list. One of the few progressives left at Canonical, so it's nice to see something you do finally not be blocked by grumpy people.

[yurikoles]

Another Canonical breakthrough!

[FireBurn]

I've been compressing my kernels with xz for years, it was certainly the smallest option when I picked it then. They're 8MB each with the firmware and drivers baked in - no modules

[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.

[ms178]

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

[eva2000]

yeah i thought zstd was planned ?

[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/

[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.