Fedora 34 Looking To Tweak Default zRAM Configuration

[waxhead]

I wonder why they don't do zswap with a dynamic swap file framework...some sort of service that turns a swap file on/off and shrinks/grows as necessary. It adds back a disk based swap if wanted/needed, allows for hibernation, doesn't waste unnecessary space when not hibernating, and brings the same benefits of zRAM in regards to low memory systems.

Agree, zswap is a much better solution. I used to use zram until I learned about zswap. They appear similar and I don't think that everyone realize how different they are. Then you got those who say "buy more ram , ram is cheap" - well on my system from 2007 (core 2 duo) the mainboard does not support >4GB RAM and even if it did I would like to use the memory modules that I have so zswap is handy from time to time.
Even on larger systems I have set up zswap because you would like to minimize the data writen to disk for swap anyway. As long as decompressing is faster than disk speed (which it usually is) there is only benefits to adding zswap.

For those interested - here is my systemd unit for enabling zswap

[Unit]
Description=Set up zswap

[Service]
Type=oneshot
User=root
ExecStartPre=/usr/bin/sh -c "echo zstd > /sys/module/zswap/parameters/compressor"
ExecStartPre=/usr/bin/sh -c "echo z3fold > /sys/module/zswap/parameters/zpool"
ExecStartPre=/usr/bin/sh -c "echo 40 > /sys/module/zswap/parameters/max_pool_percent"
ExecStart=/usr/bin/sh -c "echo 1 > /sys/module/zswap/parameters/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[FireBurn]

I wonder why they don't do zswap with a dynamic swap file framework...some sort of service that turns a swap file on/off and shrinks/grows as necessary. It adds back a disk based swap if wanted/needed, allows for hibernation, doesn't waste unnecessary space when not hibernating, and brings the same benefits of zRAM in regards to low memory systems.

Sounds like a job for systemd

[karolherbst]

i had to tweak zram to "disabled" and add real swap partition to be able to run 12gb game on 8gb box

you don't have to. You can over subscribe with ZRAM with no issues. It's just the tooling around which adds limitations.

[karolherbst]

Because this change was done at the expense of Hibernate functionality. Consumers nowadays overwhelmingly prefer laptops over desktops, and Hibernate is a very useful feature on a laptop. Taking away a feature that's useful to the majority of users, in favor of a feature that only benefits edge cases, is moronic.

you can always add real swap in addition. But swap also doesn't have to be its own partition, but also a file on a filesystem _and_ you can increase it in size whenever you install more RAM.

[ermo]

Agree, zswap is a much better solution. I used to use zram until I learned about zswap. They appear similar and I don't think that everyone realize how different they are. Then you got those who say "buy more ram , ram is cheap" - well on my system from 2007 (core 2 duo) the mainboard does not support >4GB RAM and even if it did I would like to use the memory modules that I have so zswap is handy from time to time.
Even on larger systems I have set up zswap because you would like to minimize the data writen to disk for swap anyway. As long as decompressing is faster than disk speed (which it usually is) there is only benefits to adding zswap.

For those interested - here is my systemd unit for enabling zswap

Out of curiousity, have you benchmarked using lz4 vs. zstd? I assume that there's a reason you're using zstd over lz4 in the first place?

I use lz4 because I am typically only RAM limited during (the linking phase of) compilation, which is why I prefer a compression algorithm that doesn't attempt to use the core(s) on which the linking operation is taking place.

[Vistaus]

Meh, RAM is so cheap these days, I don't see where this zRAM thing is a meaningful improvement. Seems like only small fixed-memory devices like Chromebooks or Raspberry Pi's would benefit from this. I recently installed F33 on a laptop, and one of the first things I noticed was that Hibernate no longer works on a default install. With F33's zRAM-only swap space, there is no disk based swap, so the machine is unable to hibernate. You have to manually create a swap partition at least equal to physical RAM + zRAM size, and then edit /etc/default/grub to add the "resume" kernel parameter with the UUID of the swap partition.

IMO far more laptop users in 2021 would benefit from the ability to hibernate, than would benefit from zRAM. Especially so, now that intel has eliminated the perfectly good S3 sleep state, in favor of the sh1tty s0ix sleep that keeps most of the machine powered up and kills your battery. Sorry Fedora, this new default config makes no sense.

What Chromebooks have fixed memory? My last Chromebook, the Dell Chromebook 13, didn't have fixed memory.

[waxhead]

Out of curiousity, have you benchmarked using lz4 vs. zstd? I assume that there's a reason you're using zstd over lz4 in the first place?

I use lz4 because I am typically only RAM limited during (the linking phase of) compilation, which is why I prefer a compression algorithm that doesn't attempt to use the core(s) on which the linking operation is taking place.

Yes, or rather sort of. First I found some benchmarks on the web where zstd was compared to lz4 on smaller files. On my system the page size is 4k so assuming that zswap compress page by page I assumed that the compression ratio and speed for 4k files was a suitable benchmark to base my tests on.
This is just an assumption so admittedly I don't know i this was the correct way of thinking.

Next I just overloaded the system firing up gimp and loaded lots of large pictures. Then I simply and subjectively compared switching between different pictures trying out the different compression algorithms. While LZ4 technically should be faster than ZSTD I did not notice any difference. I also tried with a game (thedarkmod) which ran best when ZSTD compression was enabled. ZSTD depending on the compression level (I don't know which level zswap use) should have better compression ratio so I chose that by default simply because A) I did not notice any difference with my simple tests, and B) since ZSTD usually has better compression I prefer that.

So just about as simple as that. Did not invest more time into it nor did I do any proper benchmarks , the conclusion is simply "it works for me", but maybe it does not work for you. I suggest running a few practical minded tests and see for yourself what fits your use case! Good luck

[cobratbq]

I don't have any experience with the "secure boot" stuff, but you can always LUKS encrypt the swap partition. It will prompt you for the password during bootup, or during resume-from-disk. If its encrypted, it's no longer "untrusted" persistent storage, yes?

So IIUC this isn't a matter of possibility but of security. To elaborate: it is possible to have a persistent backed swap drive and have hibernation work "as advertised". There is no issue there. Indeed, one can use encryption/authentication to ensure either the original content gets read back or none at all. It is feasible.

As far as I understand the Secure Boot threatmodel, any entrypoint that allows modifying read-only memory (logic, as opposed to data) must be closed off. This means, after a successful boot into the linux kernel, those paths are closed using Secure Boot system calls to enter something like a "reduced access mode". This closes off the capabilities of hibernation along with any other access to low-level boot/kernel modification, as otherwise it would also open up the possibility for corruption/infection.

Personally - and I'm not an expert on this matter by any means - I can imagine that - given sufficient freedom by UEFI/Secure Boot - if the TPM is used to appropriately encrypt/authenticate data one could argue that it is unmodifiable. However, this is only under the assumption that the TPM's secret is unattainable. However, AFAIK this isn't available. And without guaranteed unattenainble secret keys, restoring from hibernation using memory content stored persistently, because it may be accessed by other means in the mean time is a risk.

Again, I'm not an expert. This is based on what I know with some extrapolation for this use case.

[pal666]

you don't have to. You can over subscribe with ZRAM with no issues. It's just the tooling around which adds limitations.

prime limitation of zram is it wastes precious ram on systems with insufficient ram, which is very stupid thing to do. real swap doesn't waste 25% or now 50% of memory

[HyperDrive]

As long as decompressing is faster than disk speed (which it usually is) there is only benefits to adding zswap.

You do realise zswap decompresses the data before writing it to disk, don't you?