Now That The Linux Kernel Can Be Zstd-Compressed, The Next Step Is The Firmware

[phoronix]

Phoronix: Now That The Linux Kernel Can Be Zstd-Compressed, The Next Step Is The Firmware

With Linux 5.9 comes the ability to compress the Linux kernel image / initrd with Zstd for yielding faster boot speeds but at a compression ratio between Gzip and XZ/LZMA. Being proposed next with the widespread adoption of Facebook's Zstd is compressing the kernel microcode/firmware files...

http://www.phoronix.com/scan.php?page=news_item&px=Zstd-Firmware-Compress-Patch

[bug77]

I must be missing something here, but what's this fuss about compressing the kernel image and stuff? Standard kernel is ~200MB. A SATA/AHCI SSD will read that in a third of a second. A NMVe SSD will read it 5-6x faster. What gives?

[rawr]

I must be missing something here, but what's this fuss about compressing the kernel image and stuff? Standard kernel is ~200MB. A SATA/AHCI SSD will read that in a third of a second. A NMVe SSD will read it 5-6x faster. What gives?

Hardware with lesser capable hardware? I suspect embedded devices, like a lot of wlan routers, etc.
Reading the image from ROM is afaik a considerable amount of the boot time there.

[bug77]

Hardware with lesser capable hardware? I suspect embedded devices, like a lot of wlan routers, etc.
Reading the image from ROM is afaik a considerable amount of the boot time there.

Well, I'm pretty sure those kernels are well under 200MB. And kernel compression is enabled by default on desktop...

[rawr]

Well, I'm pretty sure those kernels are well under 200MB. And kernel compression is enabled by default on desktop...

Sure, but I think the use case is that when you turn on, say your shiny new action cam, you don't want to wait more than a few seconds for it to be usable.
I think optimization in software allows you to be cheaper in hardware. Saving space and being faster to boot sounds to me like something that is worth putting a little bit of work into.

[discordian]

I must be missing something here, but what's this fuss about compressing the kernel image and stuff? Standard kernel is ~200MB. A SATA/AHCI SSD will read that in a third of a second. A NMVe SSD will read it 5-6x faster. What gives?

Decompressing with lz4 is close to memcpy speed. As you typically need to move around some blocks, and io is limiting, it makes zero sense not to compress and waste space.

And I believe the bigger plan is to throw out all compression that is basically always inferior to zstd, only keeping lz4, xz and for compatibility gzip.

[rene]

background & implementation details: https://www.youtube.com/watch?v=_mGajxQ0AZY I also only mostly only use it for initrd, e.g. 20MB instead of 30MB initrd, and memory savings, e.g. ps3 in my installed OS btrfs can compress it transparently anyway, ... ;-)

[Guest]

Compressing your kernel, initramfs and so on the right way makes a difference in boot times. Even with fast SSDs, it's possible to decompress whatever it reads to get faster effective read speed.

[tildearrow]

Typo:

The proposed patch adds support so the kernel will properly deal with with decompressing

[milkylainen]

I must be missing something here, but what's this fuss about compressing the kernel image and stuff? Standard kernel is ~200MB. A SATA/AHCI SSD will read that in a third of a second. A NMVe SSD will read it 5-6x faster. What gives?

200M bzImage? WTF have you been feeding your kernels?
Oh. With initrd.
Either way. Loading from various UEFI / Legacy / Whatever load are usually pretty suboptimal.
This also adds to various other projects. Zstd is (in my book) the best tradeoff for decompression speed / compression ratio.