Disabling zswap?

[callegar]

Looks like when zram-generator is used, systems whose kernel defaults to using zswap do not get that disabled.
As a result, I presume that the system attempts to compress memory pages twice since zswap will use zram as its backing store.
I do not know if this has any adverse impact on performance, but I expect it to be the case.

Because the two mechanism are more or less two different solutions for the same problem, maybe it would be useful to default to automatically disabling zswap when using zram through zram-generator.

Also documenting the potential coexistence of the two mechanisms would be useful.

[tukoz]

Yes to this. E.g. Nefelim4ag's systemd-swap (that I've been using for years):

note, you should never use zram and zswap at the same time.

[liolok]

+1 from ArchWiki

[nabijaczleweli]

Lots of opinions here, not a lot of primary sources. I, for one, can find exactly 0 layering violations for that setup, that's true, but don't really see why layering one on top of the other would be a Forbidden configuration. This also means that any documentation of using both would be "it works as you'd expect", i.e. ∅.

Yes, you're potentially giving up some perf. You're also potentially gaining some if you pick the right compressors. They also straight up don't mingle if you're not using your zram device to swap to (this also means that the quoted fragment from "Nefelim4ag's systemd-swap" is full^W very obviously wrong).

Fundamentally, point is: they don't interact at all => we shouldn't make them do so.

[callegar]

Fundamentally, point is: they don't interact at all

• Most likely true that at least in principle they can be layered

You're also potentially gaining some if you pick the right compressors

I do not have hard numbers, but I strongly suspect that this cannot be the case. Compressing something twice, will most likely take longer than compressing it once, with little or no benefit on the compression ratio. If there were two compression algorithms that used in cascade could deliver faster performance, they would have probably already been made into a single compression recipe.

• Most likely true that by layering them you worsen the performance

In addition to that

• Layering them increases the possibility of encountering bugs, because a bug in either solution will cause problems

My two cents is that users should be free to layer the two solutions one over the other (even if just for debugging/benchmarking purposes), but this should by no means be what the average users employs and the default should not be that.

Hence, with respect to:

This also means that any documentation of using both would be "it works as you'd expect", i.e. ∅

I do not agree with it. Can you trust all users, regardless of their level of competence, to have proper expectations?

IMHO, it is polite and helpful and has educational value if the documentation of a project happens mention alternate solutions and does not entail "making the two solutions interact". So, I think that the documentation should mention zswap, clearly indicate that it is an alternate solution and not something meant to be complementary to zram and point out that using both at once should "work as an expert user may expect" that is with no data loss but most likely with degraded performance wrt using just one of them and at a higher probability of encountering bugs.

Not having this, will just cause distro or help sites provide their own documentation layered on top of the official one of zram-generator, which also works as you'd expect: at best in a confusing way, at worse providing conflicting or incorrect information.

Furthermore, I think that it would be kind to the non expert user to have zram-generator provide a config option like disable-zswap defaulting to true.

[nabijaczleweli]

My brother in christ, running lz4 before zstd is faster in the general case than just running zstd: openzfs/zfs#13244; lz4ing in zswap, with spill into zstd swap-on-zram, with spill to backdev/lower-priority swap, while not fully identical, is largely equivalent.

As it stands, the default is to not interact with an "(EXPERIMENTAL)"(!) off-by-default kernel feature (for which the last five commits in mainline appear to be userspace escape bugs and support for basic statistics, befitting of the "(EXPERIMENTAL)" tag) – this mirrors them being independent in the kernel as well. An administrator explicitly activates and configures s/z-g, and an administrator explicitly activates and configures zswap. If your distributor configures with ZSWAP_DEFAULT_ON=y then yell at your distributor for introducing a security vulnerability in the default configuration.

So, yes, I can: an administrator who has enabled zswap is, ex def., aware of what zswap entails.
zswap and zram do not interact: zswap is a feature of memory management, and zram is a block device.

This reeks of the iwd situation – that being iwd having started to automatically take over wireless interfaces in their entirety, including nomenclature and configuration, which it has no business doing, as part of an update, which, as you may expect, made a lot of people very angry because it Just Broke Their Network Configuration And Finding Out Why Was a Pain in the Arse – to me.
If you're using zswap and want to stop doing that: take out zswap.enabled=1 from your cmdline, don't expect unrelated software to meddle in your system configuration.
(Plus, do you expect s/z-g to.. parse the cmdline to find the toggle and not turn it off if it's true explicitly? Always turn zswap off? Across sd reloads? Now that's an out-of-memory scenario waiting to happen. There's no reasonable way to handle this that wouldn't be insane. This is not s/z-g's configuration to set (calling it a layering violation may be overzealous, but, well).)

[callegar]

running lz4 before zstd is faster

Out of curiosity and to learn something: isn't that observed because lz4 is better at identifying incompressible data and give up, so that you can have scenarios where if lz4 gives up you also skip the zstd pass or you run it with different options? If so, isn't the ZFS situation incomparable to the current one? Being zswap and zram unaware one of the other, the zstd pass cannot be "guided" in any way by the previous lz4 one, can it?

If your distributor configures with ZSWAP_DEFAULT_ON=y then yell at your distributor

Did not know that zswap was still considered experimental having been introduced in 2013. Nice to learn. This seems to imply that at current time you should not have zswap on at all by default. Yet that assumption may change in the future.

zswap is a feature of memory management, and zram is a block device

correct, but we are not talking about zram tout court here, we are talking about zram-generator that describes itself primarily as a “mechanism to configure swap”, a memory management feature, not as a general mechanism to configure ram based block devices (even if it can probably also do that).

I would 100% agree with you if we were talking about zram itself. But here we are talking about a configuration tool for using zram for swap. Configuration tools usually are generally meant to simplify the life of users and admins and make their setups more robust and correct (otherwise admins could very well write themselves whatever is needed for the configuration). For this reason IMHO it is not totally out of scope for a configuration tool to look at the system setup with a slightly larger scope.

Do you expect s/z-g to.. parse the cmdline to find the toggle and not turn it off if it's true explicitly?

No, that would be wrong even from my point of view. Still I remain convinced that the s/z-g documentation should mention zswap and indicate that before activating zram for swap one should check for the status of zswap.

Probably, on the activation of zram for swap, s/z-g could also read /sys/module/zswap/parameters/enabled and log if it finds it to be 'Y' with a warning that this configuration may be suboptimal. One log line in the journal per boot does not seem a big issue for someone who explicitly wanted that configuration and would be a convenience for anybody else.

Maybe, and just maybe, s/z-g could also have a configuration option, so that if it finds /sys/module/zswap/parameters/enabled to be 'Y' and the configuration option is on, it writes an 'N' in there.

Apart from this, I must say that after this exchange I am now convinced that the correct place to address this issue should be in the distribution packages, though. It should be the install script in the distro package to check the state of zswap at the package install time and warn if it finds it on suggesting that you switch it off. But distro packagers will likely never consider that unless the s/z-g documentation itself mentions zram.

[ReillyBrogan]

Zswap is no longer considered experimental as of Linux 6.1: torvalds/linux@fcab9b4.

[renyuneyun]

I may be naive as I didn't previously consider all these things but recently come across them.
I have a swap partition equal to the size of RAM. However, I often find memory being eaten up quickly (both swap and physical RAM), so I'm now configuring zram to get more working RAM.

It seems zswap will operate on all swaps while zram may be one of them; and there is no way to configure zswap for a part of swap only.

Therefore, disabling zswap by default will also disable zswap for actual swap partitions/files, right? They are not compressed on them own, and should benefit from zswap.

Thus, it should be up to the administrator's decision to either use zswap or not, based on whether they have swap partitions or not and their actual needs.
(But I agree it could be an option in zram-generator's configuration file for easier set up.)

[chromer030]

Option in /etc/systemd/zram-generator.conf to turn it off before activating zram is a need.

[OmegaSquad82]

zswap will decompress any page which is to be written to the backing swap device(s).

[es20490446e]

Just check if there's any other swap in /etc/fstab, and if there isn't automatically disable zswap.

This is what I'm going to implement on the service file within my zram-generator package for the moment being.

[es20490446e]

I solved it in my package by using these modifications, in case it serves you as reference.