Fedora 34 Looking To Tweak Default zRAM Configuration

[nivedita]

With ZFS enable compressed swap VDEV does exactly the same without additional code in the kernel or adding additioanl systemd unit service (because ZFS keeps in ARC compressed VDEV records)

Swap on ZVOL is unsupported and can cause system crashes.

https://github.com/openzfs/zfs/issues/7734

Also, ZFS doesn't support hibernation.
https://github.com/openzfs/zfs/issues/260

[torsionbar28]

Hibernation is a bit of an issue due to the security model of Secure Boot. You cannot have "trusted memory" saved to "untrusted persistent storage" and then shutdown the computer only to later read it back into memory and blindly trust that no-one has accessed your secrets/modified your data. That is/was one of the "big users" of swap space and has become more or less obsolete. (At least for the UEFI/Secure Boot use-case.) ... not a full answer to your question tho.

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?

[torsionbar28]

Ram may be cheap, but laptops aren't and manufacturers like to solder ram chips.

Shrug. Buy a better laptop? Hibernate is highly useful on a laptop regardless of memory config. The default installation should cater to the majority use case, not the weak hardware edge cases.

[torsionbar28]

I really don't get why some people are "against" such changes, as using zram instead of disc swap already gives user more storage as there is no point bloating wasting disc space for swap anymore with zram/zswap.

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.

[pal666]

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

[pal666]

With ZFS enable compressed swap VDEV does exactly the same without additional code in the kernel or adding additioanl systemd unit service (because

because zfs zealots do not understand that zfs is "additional code in the kernel"

[polarathene]

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.

I can't quite recall, does zram limit allocations by uncompressed input or compressed? (eg 1GB RAM, 1GB ZRAM, ZRAM can compress up to 1GB of uncompressed input and remaining unused space is available to remaining memory for allocation, even if ZRAM could compress more pages to squeeze in more compressed memory?)

If so then sure you'd say about 2GB of Swap is required as hibernation would swap out decompressed pages from ZRAM. Otherwise that'd be a bit more difficult to predict max required swap space to hibernate? Note that hibernation does compress memory by default (I think it has a 40% target?), so it may be possible to fit into 1GB swap still depending how compressible input is.

---

If you add a swap partition or file to the mix, you'd want to avoid the system using that for general swap and only toggle it on/off for hibernation, otherwise you can run into problems when the system uses it for swapping memory pages once zram fills up (which btw can further complicate performance if zram holds onto stale/inactive pages instead of evicting to slower storage based swap which may get the newer more frequently accessed pages the system swaps out).

Especially a concern if you want to encourage the system to swap to zram for the compressed advantage, since vm tunables like swappiness are device wide, not device specific (been an issue in the past regarding slower USB external storage like cheap flash sticks vs internal SSDs where you want to balance vm tunables like how soon to flush a memory buffer to disk during file transfers, the cheap/slow storage needed to flush sooner which improved sync and being able to unmount hours earlier, but faster internal storage would lose some perf advantages). Adding a swap to disk storage you probably want to avoid encouraging the system to swap to, so while you could assign priorities to favor filling up zram first, afterwards if there's spare memory the kernel may still actively take preference to moving pages to swap when possible which may start to backfire at that point.

You can workaround that with some automated recurring task to empty out the zram device(s) to disk storage routinely and recreate the zram device again. In this context, for just hibernation you don't want the swap around anyway, so if you're going to automate such behaviour you'd just do such with hibernation/resume, there's some guides online about doing this with systemd (which on most systems with systemd afaik is what hibernate commands tend to defer to anyway). You technically don't even need to setup `resume` for this, systemd will actually look for a swap partition if that kernel boot param is missing and take a guess at what swap device to use(if more than one), otherwise it'll use whatever your kernel params specifies.

---

Some users btw expressed back in 2018 with Fedora 29 testing that they were not fond of hibernation (or rather a suspend with delayed hibernation).

Fedora made the decision against supporting hibernation last year though. It seems like a fairly documented pro/cons for making the decision, notably one concern was the large swap space, which with the above mentioned systemd automated toggling for using it for hibernation only and zram for general usage swap, that's probably one issue that's being taken care of to make hibernation more acceptable? The bottom also hints interest from Fedora to support such, in a way that hibernation isn't supported by default but would be easier for a user to enable post-install.

Ubuntu also claims they no longer support hibernation by default either btw.

[polarathene]

If ZRAM doesn't compress well and uses most of the RAM, that can present a perf/thrashing issue right? ZRAM doesn't get used for file cache and I assume a few other things?

But when pages from swap are accessed, they're copied to RAM (while keeping the copy in swap still IIRC) yeah? So in low memory scenario if application data of 500MB was being frequently accessed with 200MB available memory there would be a lot of compression/decompression going on? (or just decompression if the memory isn't being modified and can re-use already compressed zram swap pages?) At the same time, I guess any disk files that get cached may be dropped and read in again from disk when needed?

ZRAM is allowing you avoid the issue better than no swap at all, but is it possible to cause a negative experience if the ram it utilizes is set too high? EDIT: Fedora devs discussed this back in 2019, they tested with ZRAM being sized to 25% and 100% of system RAM (8GB), they express 100% is too high but 25-33% is probably good, ChromeOS uses 66%(3:2 ratio).

What happens if ZRAM has spare capacity (eg you allow 10x your RAM capacity) but your actual available memory is low (possibly filled with compressed pages in ZRAM), does the kernel still think there is all this additional unused allocatable swap space available? Probably a silly question as you shouldn't be sizing it so high, even at 100% of RAM, the kernel would assume for 1GB RAM that it has 1GB of swap too?

I should probably just test zram out myself to answer this, I assume RAM is allocated on-demand to ZRAM as it adds compressed pages, but the available swap would be the uncompressed limit, so for 2:1 compression ratio on 1GB of memory, you fill up swap and use 500MB of RAM, and the kernel would see 500MB of RAM available with no swap? So long as the compressed swap can allocate to available RAM you're fine, but presumably things go bad if the kernel thinks there is spare swap available but not enough actual memory spare to compress pages to?

I recall reading of one scenario where a user had a low memory process that went through a filesystem analyzing lots of files over several hours, if left idle all their desktop apps were paged out to swap on HDD to cache file reads which took over 30 minutes for them to be able to say resume using Firefox for example. It's not something that would likely be a concern with ZRAM but still an interesting case of swap on disk working against the users benefit.

---

I'm all for ZRAM, just curious at what point/scenario it might cause problems that you wouldn't run into with regular swap on disk.

[patrakov]

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?

If it is encrypted by your key, it is still untrusted by the company who wants to run nothing in kernel mode except what they have specifically approved. It is still something you (the enemy) can tamper with.

[finalzone]

That's interesting, but is a totally different use case. Fedora is a Workstation OS. You're describing a server use case. I agree it could be beneficial on a server, and likewise hibernate is fairly useless on a server. But again, that's not what my comment was in reference to.

Similar experience on Fedora Workstation when compiling Blender. Zram helped on that scenario depending of the allocation which is dynamic.