Enable lz4, lz4hc and zstd compression support for zram for kernel 6.6

[fwilhe]

What this PR does / why we need it:

Back porting #67 for the 6.6 line

Which issue(s) this PR fixes:
Fixes #66

[pnpavlov]

@gehoern , can you please review and confirm if this change should be also in 6.6 (therefore 1443 and 1592 upcoming patches) or only in the 17 release?

[nkraetzschmar]

my 2 cents:

• enable the options: sure, why not
• change the default: maybe not.... while zstd gets you very good compression ratios there is far more overhead compared to lz4, so default lz4 is probably preferred

[fwilhe]

@nkraetzschmar fyi, this is the pr for 6.6., on main for 6.12 it is already merged with the same default. No one objected to that before, if you would like to change this before we release a new version, please put that forward.

[Vincinator]

Those are not defined in Linux 6.6.79

[fwilhe]

Hm, I thought I checked this, but maybe I made a mistake there.

Thanks for pointing that out.

Shall we close the PR, or is there a sensible replacement for those configs?

[Vincinator]

In linux 6.6 the crypto submodule provides an interface to the compression algorithms defined in lib, e.g lib/lz4.

In 6.6 we have a chain:

• CONFIG_ZRAM depends on CRYPTO_LZO which selects CONFIG_LZO_COMPRESS
• other compression/decompression functions are cascaded similarly with kconfig

Will check tomorrow what we need to enable in our configs

The interface changed in later kernel versions to a dedicated ZRAM compression backend with this patch series

[Vincinator]

For the non-cloud kernel we have

CONFIG_ZRAM=m
CONFIG_CRYPTO_LZO=m
CONFIG_CRYPTO_LZ4=m
CONFIG_CRYPTO_LZ4HC=m
CONFIG_CRYPTO_ZSTD=m

(see here)

So it should be possible with 6.6, also according to the linked issue and the mentioned debian bug report (since we do not automatically pull in Debian's kernel config, but explicitly define all configs in our source tree, I double checked)

Starting with kernel 6.12 ZSTD compression is no longer available for ZRAM.
It used to be available by default.

So I would agree with closing this PR for now