systemd
Add support for new zram features (recompression, etc)
There have been changes afoot in the zram kernel module... Most notably, the addition of zram recompression: https://github.com/torvalds/linux/commit/84b33bf7888975d28c0e57011b75c445279c60ec
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 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?
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
No point configuring
recomp_algorithminzram-generatorif we don't trigger recompression v0v
Based on @nabijaczleweli response here: https://github.com/systemd/zram-generator/issues/164#issuecomment-1336507415
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)
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.
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.
