What is the consensus on enabling ZRAM by default going forward in Ubuntu? I have personally seen excellent results in 22.04 with it, and it appears that both Windows and MacOS are now using memory compression, along with other distros such as Fedora and Pop!_OS. Both the general smoothness of operation and the alleviation of wear and tear on SSD’s via swap files are benefits I feel are worth considering.
Thanks for your time.
(IMO) I do not believe zram is well aligned with how we deal with memory in Ubuntu. We do enable swap files on Ubuntu, and zram is strictly inferior to zswap if you have actual swap files/partitions. It’s much harder to setup and not really built for this use case, whereas zswap is literally just swapping one module parameter to true to enable it.
zram is very easy to setup nowadays: you only need to install the package. I’ve gotten very good results but I’ve also seen new errors and that bothers me a bit.
I’ve never been happy with the default 50% rule. I think this is because with, say, 1GB of RAM and a 3:1 compression ratio, zram will store 0.5G as 0.17G, therefore freeing 0.33G. You now have 1.33GB usable, or +33% memory. That’s actually not a lot: sure it’s a bit more but it probably doesn’t let you do more or run apps you couldn’t run before. That’s why I’ve always used much higher percentages, like 200% and zstd compression. And I don’t think these values could be used by default.
I’ve been using zram to eliminate swap files from my systems. One is a ‘do it all’ 32GB rig used for both work and play with a 100% config, and one is an 8GB desktop. I’ve had a great experience on both, and it’s IMO nice to spare a few writes to the SSD’s in the process. On the 32GB system zram + no swap file it enabled playing Star Citizen’s pre-alpha with zero issues, whereas even a large swap file with no zram caused the system to tank down into unresponsiveness once memory usage approached 100%. That’s very impressive (surprising even) for my use-case. I am now testing with heavy virtual machine loads on the same machine to see how things go.
I can add some notes on my experiences activating zswap by default on the
Ubuntu Desktop for Pi images, and the thinking on why I didn’t replicate that
on the Ubuntu Server for Pi images. Firstly though, some basic clarification in
case anyone’s not aware:
zram works with or without a swap file, and effectively acts as compressed
swap media
zswap only works with a swap file, and acts as a compressed cache for pages
entering the underlying swap
General consensus at this time I was looking into this (for impish … possibly
jammy, maybe?) was that if a swap file is present, zswap was the preferable
system as it wasn’t independent of the existing swap media (from some recent
reading it appears they may be more nuance there now, though I’m not sure that
conclusion’s actually changed yet).
Regardless, both systems increase overall available memory by utilizing some
chunk of RAM as a compressed swap space (whether that’s actual swap or cache
isn’t that relevant). An important facet to acknowledge here is that both
systems reduce available RAM. You can’t directly use pages in swap (either a
real one or a compressed RAM one); they still have to be swapped back in
(albeit much more quickly from compressed RAM than disk), so by dedicating some
of your RAM to compressed swap (of either kind) you do reduce the RAM available
for general usage.
The situation for the Pi images was as follows:
The case for enabling zswap on the Desktop images was fairly clear. The base
model of Pi supported was the Pi 4 with 2GB of RAM (now the Pi 4 with 4GB of
RAM), so we knew that even with 20% (the default) allocated to zswap there
would still be >1.5GB of RAM left, and furthermore a 1GB swap-file was already
allocated on first-boot so there would definitely be backing for the zswap
cache.
On the Ubuntu Desktop for Pi images, enabling zswap with zstd compression
and the 3:1 pool allocator (giving maximum potential compression of 3:1 per
page) changed the memory layout in the 2GB RAM case as follows:
┌───────────────────────┬────────────┐
│ 2GB RAM │ 1GB Swap │
└───────────────────────┴────────────┘
┌───────────────────┬────────────────┬────────────┐
│ 1.6GB RAM │ 1.2GB ZSwap │ 1GB Swap │
└───────────────────┴────────────────┴────────────┘
(effective)
Hence, we sacrifice 20% of available RAM to increase total (effective)
available memory space by 26% (1.6+1.2+1 / 2+1). Not a huge improvement, but
crucially not worse. Further, it also provides a “smoother” progression as
memory pressure increases. Instead of going straight from super-fast RAM to
incredibly slow swap, the system can now go from super-fast RAM, to
“suspiciously fast” swap (the compressed portion), and eventually to incredibly
slow swap (and yes, there’s plenty of subtle details I’m skipping over here
like uncompressable pages going straight to disk and so on; none of this is
“cut and dried”).
The 4GB RAM case changed as follows:
┌──────────────────────────────────────────────┬────────────┐
│ 4GB RAM │ 1GB Swap │
└──────────────────────────────────────────────┴────────────┘
┌──────────────────────────────────────┬────────────────────────────┬────────────┐
│ 3.2GB RAM │ 2.4GB ZSwap │ 1GB Swap │
└──────────────────────────────────────┴────────────────────────────┴────────────┘
(effective)
Here, the gain is more prominent. We sacrifice 20% of available RAM to increase
total available by 32% (3.2+2.4+1 / 4+1). I didn’t worry too much about the Pi
4 8GB case because, if you had that model you probably don’t worry much about
swap anyway.
So that was the case for Desktop. How about the Ubuntu Server for Pi images?
Here the story was much more difficult:
The minimum supported model was (and still is) the Pi Zero 2W and 3A+ both
of which have a minimal 512MB of RAM. Sacrificing pretty much any of this
is extremely risky, and recall that the smaller the RAM sacrifice the smaller
the overall gains.
No swap file is created by default. The server images run in a multitude of
environments and configurations, including netboot, overlayroot, etc. In
several cases, swap was undesirable which more or less ruled out zswap (and
I really didn’t want to contend with two different compression systems across
images).
Suffice it to say, I decided that the case on Server was weaker and too
variable to confidently persue. I haven’t verified this, but personally I
harbour a suspicion that 2GB of RAM is probably the lower bound where these
systems are genuinely useful. There’s also the aspect that a user of Server is
probably more confident in configuring zswap or zram themselves, should they
feel it necessary.
Concluding: I suspect that the above reasoning may apply, at least partly, to
the Ubuntu PC images too. I can see a case being made for Desktop fairly easily
(either zram or zswap – I’m not going into the weeds on that one without some
serious data to back me up!). The case for Server is much harder and, I think,
weaker for similar reasons (wider range of hardware, configuration scenarios,
overruling preferences of server admin, etc. etc.)
I wonder if something like an “enable ram compression” button in the advanced partitioning dialog of the installer (i.e. the thing you picked because you did want to do a technically advanced setup anyway) might make sense here…
Thanks for the insight! I agree on this being more of a desktop concept at this time. I can appreciate from professional experience that in a server scenario, predictability is king and administrators will build and tune to meet particular needs.
A nice idea! Personally (as mentioned above) I think the case for this being enabled by default on desktop is pretty strong. In which case, such a control could be used (in the desktop installer case) to disable the feature, should the advanced user desire it.
In the server case, the opposite default could apply, and it could be used to enable it, if desired (and if some swap device was configured).
Any support for this as 24.04 nears?