On Sun, Jun 7, 2020 at 12:56 PM Konstantin Kharlamov <hi-angel(a)yandex.ru> wrote:
Hello! I see a proposal to enable zram by deafult¹. If I correctly
understand this is the thread where it's being discussed. I have a few
questions, answers to which probably would be nice to add to the
1. It says ZRAM gets enabled on upgrade. What's gonna happen to systems
with ZSWAP is enabled? I guess it doesn't make sense to keep them both.
Good question! I will add this to the feedback section.
- there is no immediate conflict between them, system will boot
normally and there will be no errors in the journal
- since you've already decided to dedicate X% to zswap's cache, which
is a preallocation, the feature does intervene in your preferred setup
by favoring the swaponzram first, before the workload hits zswap. And
only if it fills up the zram device first.
That will disable this feature.
2. I was a bit shocked to see comparison to a system with 16GB of
I admit the more the better, but most people still have only 8GB on
their laptops/PCs, and sometimes there's just 4GB of RAM.
My question is: given people with 4GB of RAM, are you sure that
handing 2GB over to ZRAM gonna improve their experience?
Yes. Not that while zswap's cache preallocates memory. Whereas the
zram module does not preallocate memory to /dev/zram0. It's used only
So in the 4G RAM case, a 2G zram device will use 256M-1G of memory
depending on the compression ratio (which I'm seeing 4:1 to 2:1).
The third question touches the paragraph "Why not zswap?". The only
point it mentions is that swap-device is not encrypted. Fair enough,
although I wonder why this never has been regarded as a problem before.
It's definitely regarded as a problem. Perhaps not quite on par with
user home not being encrypted but swap is known to be a potential
source of leaking user data. To a lesser extent, /var and /etc. And
also the initramfs is a weak point too, in that it's not signed.
Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
enough! The moral of this story is that you can't get away with only
ZRAM without any disk SWAP. You need disk SWAP. And if you have disk
SWAP, ZSWAP fits more nicely there as a compressing buffer before the
data finally spills over to disk.
Your use case is intentionally overcommitting available memory and it
sounds like you don't have much choice in that you (a) the workload
you have is the workload you need to run, and (b) memory isn't
You should consider testing whether swap-on-zram sized to 100% RAM
fits your use case better. And in fact if your workload gets very good
compression ratios, it can be quite reasonable to go higher than 100%.
An alternative explanation is that you've found the sweet spot with
the zswap setup you have already.