RFE: default settings for all zram devices

[Mek101]

Having to specify a [zramN] section for each CPU core can extremely redundant on machines with many cores. Would it be possible to add a [default] section, to set the configuration of all devices, unless it's specifically overridden by the section of the single device?

[ignatenkobrain]

Not too much related to the issue itself, but I'm curious…

section for each CPU core

What's the reason for this?

[vilgotf]

I think they're referring to old versions of Zram that didn't do multi core (fixad as of 3.15). docs.

[Mek101]

I'm talking about the structure of zram-generator config file

[nabijaczleweli]

Sure, but beside the RFE (which I find rather superfluous, seeing as printf '[zram%d]\nzram-fraction = 0.017\n\n' $(seq $(nproc)) > /etc/systemd/zram-generator.conf works), why do you want to generate 112 zram devices instead of, like, just one 112 times as large?

[Mek101]

What

---

Sorry mobile formatting made everything illegible

[Mek101]

(which I find rather superfluous, seeing as printf '[zram%d]\nzram-fraction = 0.017\n\n' $(seq $(nproc)) > /etc/systemd/zram-generator.conf works

Works until you have to update something and you have 1 or 2 devices with a different configuration, then you have to copy those different configs away, generate a new file file and repatch it

why do you want to generate 112 zram devices instead of, like, just one 112 times as large?

Parallelism

[nabijaczleweli]

Is this, like, measurable? I don't really believe you're gonna get more/better/faster processing by doing smaller batches.

[keszybz]

From the kernel docs quoted by @vilgotf:

Regardless of the value passed to this attribute, ZRAM will always allocate multiple compression streams - one per online CPU - thus allowing several concurrent compression operations.

[keszybz]

To summarize: the original motivation was apparently to have multiple devices to allow parallellization, which actually is implemented internally in the kernel. Nevertheless, the approach to have default settings could be useful to some extent, e.g. for mount points. But I would like to see some actual use case before adding new functionality.

[610th]

I hijack this issue with a related thing.

I'm quite lazy and stupid, so I just copied mount-point = /var/tmp from the README when I specified mount-point in my zram-generator.conf. I suspect that this caused illegal permissions to be set to /var/tmp. It broke my flatpak (and probably many other things). Later I realized that the high quality hack actually applied to me. I don't know much about systemd and generators (nor am I eager to learn), I just wanted to get zram up and running ASAP and zram-generator seemed easy to use, plus I like Rust.

It might be wise to specify some different mount-point in the README. Why is /var/tmp being used? I bet I'm not the only one being lazy and stupid.

[nabijaczleweli]

This is a very good point (and /var/tmp is (supposed to be :v) guaranteed-persistent across boots). I've updated the README to point at /var/compressed instead of /var/tmp in the referenced commit.