Fedora 34 Looking To Tweak Default zRAM Configuration

[phoronix]

Phoronix: Fedora 34 Looking To Tweak Default zRAM Configuration

Last year with Fedora 33 zRAM was switched on by default. The setup was that using a compressed zRAM drive for swap space leads to better performance and in turn a better user experience. Some spins of Fedora have been using swap-on-zRAM by default going back many releases while since F33 it's been used for all spins. Now with Fedora 34 the configuration is being further refined...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-34-zRAM-Tuning

[torsionbar28]

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.

[skeevy420]

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.

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.

[cobratbq]

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.

[kloczek]

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)

[andreano]

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. It should be as easy as to add zram in addition to normal swap, set the zram's swappiness higher, so you normally only use that, and add swapon/swapoff for zram in the right systemd hibernate file.

[darkbasic]

Meh, RAM is so cheap these days

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

[patrakov]

Seems like only small fixed-memory devices like Chromebooks or Raspberry Pi's would benefit from this.

Disagree. About a month ago, I had to enable zram temporarily on a farm of big servers with 128 GB of RAM each (as we couldn't find enough SSDs for a temporary swap space). The memory hog this time came in the form of Ceph OSDs that eat insane amount resources during their ShallowFSCK work. And for upgrading from Ceph 12.2.x to 14.2.x, a ShallowFSCK is mandatory, and ceph-ansible wants to restart all OSDs on a host (we had 16-20 of them on different hosts) at the same time.

The Ceph upgrade procedure went smoothly, the peak zram usage was 36 GB.

[karolherbst]

Disagree. About a month ago, I had to enable zram temporarily on a farm of big servers with 128 GB of RAM each (as we couldn't find enough SSDs for a temporary swap space). The memory hog this time came in the form of Ceph OSDs that eat insane amount resources during their ShallowFSCK work. And for upgrading from Ceph 12.2.x to 14.2.x, a ShallowFSCK is mandatory, and ceph-ansible wants to restart all OSDs on a host (we had 16-20 of them on different hosts) at the same time.

The Ceph upgrade procedure went smoothly, the peak zram usage was 36 GB.

I wouldn't even be surprised if using zram even improves performance in those cases anyway. Sometimes systems have high RAM usage spikes for whatever reasons. Even on my developer machine with 32 GB RAM I hit it and sometimes I just have some amount of memory in swap.

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.

[torsionbar28]

Disagree. About a month ago, I had to enable zram temporarily on a farm of big servers with 128 GB of RAM each (as we couldn't find enough SSDs for a temporary swap space). The memory hog this time came in the form of Ceph OSDs that eat insane amount resources during their ShallowFSCK work. And for upgrading from Ceph 12.2.x to 14.2.x, a ShallowFSCK is mandatory, and ceph-ansible wants to restart all OSDs on a host (we had 16-20 of them on different hosts) at the same time.

The Ceph upgrade procedure went smoothly, the peak zram usage was 36 GB.

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.