search

systemd / zram-generator

Systemd unit generator for zram devices
MIT License
575 stars 48 forks source link

Add support for new zram features (recompression, etc) #178

Open danieldjewell opened 1 year ago

danieldjewell commented 1 year ago

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 commented 1 year ago

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

danieldjewell commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

No point configuring recomp_algorithm in zram-generator if 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)