LZ4 Support Revised For Faster Restore From Linux Hibernation

[phoronix]

Phoronix: LZ4 Support Revised For Faster Restore From Linux Hibernation

Published originally back in October were a set of patches for allowing different compression algorithms for the Linux hibernation image to yield faster restore times. That work -- focused on LZ4 compression support -- has been revised as it works toward the mainline kernel...

https://www.phoronix.com/news/LZ4-Linux-Hibernation-v2

[Anux]

It's good that they made it switchable but are they really expecting every user to make their on benchmark and select the algorithm themselves?

The actual benefit differs between each CPU (ARM single core at 300 MHz to x86 16 core at 5 GHz) and storage (HDD, flash, SSD) combo. It would be much better if they ran a short benchmark on installation to determine which combo works best on the given system.

[aviallon]

It's good that they made it switchable but are they really expecting every user to make their on benchmark and select the algorithm themselves?

The actual benefit differs between each CPU (ARM single core at 300 MHz to x86 16 core at 5 GHz) and storage (HDD, flash, SSD) combo. It would be much better if they ran a short benchmark on installation to determine which combo works best on the given system.

This could be done by a distribution, actually.

[rene]

Stop the presses, with 0.6s faster resume time the year of the Linux desktop is finally upon us!

[timofonic]

Would Zstd be feasible for this?

[piotrj3]

Would Zstd be feasible for this?

Very good on HDD/slow SSD as it yields better compression ratio and at that speed you would be probably I/O bound anyway. 9700K is around ~~2GB/s decompression with ZSTD. LZ4 meanwhile can go 4.5GB/s decompression.

Generally if you take purerly decompression time, fastest almost always will be LZ4 HC. The problem is compression speed also here matters because starting hibernation means you want to compress all of that. There LZ4 is just a bit faster then ZSTD, while LZ4 HC is a lot slower.

[skeevy420]

Would Zstd be feasible for this?

Yes, and it could potentially be the best if optimized. To optimize it there would need to be a benchmark that tested the different levels, fast included, in relation to your CPU performance and drive read/write speeds.

[jeisom]

Stop the presses, with 0.6s faster resume time the year of the Linux desktop is finally upon us!

I know you are joking, but don't forget that currently people are specing out systems with more ram as well. I don't know what the ram config on those benches are, but the benefits are going to be more pronounced on a system with 64GB, 128GB or more of ram.

[milkylainen]

500M/sec seems a little slow for LZ4. Is it because it's resuming over a single thread or something?

[Juke1349]

It's good that they made it switchable but are they really expecting every user to make their on benchmark and select the algorithm themselves?

The first step to figuring out "the best", is to make the different comparisons possible in the first place, which this foundational work is doing: making it switchable at all

Additionally, because it's switching from custom, hardcoded LZO to the kernel-wide compression API, future algos become automatically available.
Even better, we might finally get encrypted hibernate (easily) possible via these generic APIs (not wired up for custom LZO).
That would unlock hibernate under secure boot, where it's currently disabled (an evil maid could replace current unencrypted hibernate image with malware)