Zstd-Compressing The Linux Kernel Has Been Brought Up Again

[omgold]

Pitty lz4 was'nt in your test.

The results shown match very well with mine (which a posted here quite a while ago, but can't find currently). To answer your question, lz4 is the best choice for at low compression levels (fastest for given compression ratio).

The conclusion is the only algos worth keeping are xz, zstd and lz4.

[omgold]

I was thinking zstd would be great for compressed zswap too.

It is available for zram on newer kernels.

[ms178]

There is a trend to always chase the "new shiny" to always say.. oh the Macintosh is out the terminal is obsolete GUI only. Or Plan 9 makes Unix obsolete! Sometimes the new thing really sucks and people don't see the value in the old methods. We don't advance as fast as we think.

So be careful here.. however with this one I agree with you. Zstd or LZ4 sounds more optimal.

I understand that the new and shiny thing is not always really the best solution but therefore I like the need for hard facts which prove that usefulness (especially in this case it is not too hard to measure).

[eva2000]

The results shown match very well with mine (which a posted here quite a while ago, but can't find currently). To answer your question, lz4 is the best choice for at low compression levels (fastest for given compression ratio).

The conclusion is the only algos worth keeping are xz, zstd and lz4.

indeed though for me would pxz (multi-threaded xz), pigz (multi-threaded gzip, pbzip2 (multi-threaded bzip2) and zstd - these are my go to for compression as zstd negative compression levels can also be used for faster compression speed at expensive of compression ratio/size.

[Guest]

Then by all means tell them how to wait even less, using S3 sleep instead of rebooting.

What if you need to reboot, for instance after upgrading the kernel? I prefer shutting my computer down, because I've experienced high battery drain when suspending to RAM.