Add support for new zram features (recompression, etc)

[danieldjewell]

There have been changes afoot in the zram kernel module... Most notably, the addition of zram recompression: torvalds/linux@84b33bf

see also: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#recompression

Would be nice for zram-generator to support these new features :)

[nabijaczleweli]

These look like single-time triggers, so same as #164.

[danieldjewell]

@nabijaczleweli As far as I'm aware: the new recompression features are automatic - no userland trigger is required, it's all handled in the kernel? (i.e. No userland daemon is required to manage/trigger anything - just like how once zram is setup initially and the kernel is notified to use it as a swap device, it's hands-off from there...)

As a result, I believe it's more of a change to zram-generator to support the new configuration parameters?

[nabijaczleweli]

The only configurable bit is recomp_algorithm. The recompress endpoint, well, recompresses the pages you tell it to (this is easily proven by seeing that zram_recompress() is only called by recompress_store() and those two are the only code added in the patch you linked, and at a skim that's the only relevant part of that patchset), and behaves the same as writeback in this regard. No point configuring r_a in z-g if we don't trigger recompression v0v

[polarathene]

No point configuring recomp_algorithm in zram-generator if we don't trigger recompression v0v

Based on @nabijaczleweli response here: #164 (comment)

While zram-generator could generate timers based on some config to support that feature (and I assume the same with this recompression one), it's not being considered relevant to support and users should DIY their own?

---

Seems like the timers with basic config options would meet many users needs of those features, and it'd kind of fall into covering more zram functionality which seems relevant to the project (simple and fast way to configure swap on zram), along with it's secondary goal of demonstrating a systemd generator in rust by additionally creating timer units? (probably wouldn't differ that much though..)

Only valid argument then is the convenience of having timers generated alongside the generated units, and the user config kept simple via the same zram-generator config?

For users that would be interested in these zram features, is there much benefit to them all DIY managing their own timers for pairing with the zram-generator generated units?

---

I understand if there is little interest from maintainers to implement that support, but would you be open to contributors providing a PR, or would it be a waste of time? (I'd usually be open to it, but not sure when I'll have time spare)

[OmegaSquad82]

Hi, this would imo be a nice feature to have both, namely that the

a) recomp_algorithm is configured during setup of the zram block device and then
b) creating some timer(s) which trigger recompress at regular intervals, best selectable which pages to handle.

I'm writing this on a fairly old 4GiB Netbook which profits from overcommitting system memory through zram swap with lz4, running Firefox along with several Electron shells (like Codium, Signal, ...) but I do wish there would be some convenient way to increase the ratio for cold and/or huge pages.

[nabijaczleweli]

Configuring the recompression algorithms is definitely within the scope here (but not something that's obvious to test because Debian configures without CONFIG_ZRAM_MULTI_COMP; I hope you'll test this if I ping you on a PR).

Generating a plain timer unit that does echo "whatever specific thing" > /sys/block/zram123/recompress is equivalent to a cron job, so add it to your crontab. This will also make it much easier to test.

[OmegaSquad82]

Thank you so much for adding this. Will build and test it.

[OmegaSquad82]

LGTM