On Sun, 2020-06-07 at 18:19 -0600, Chris Murphy wrote:
On Sun, Jun 7, 2020 at 12:56 PM Konstantin Kharlamov <
> 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
> 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
> with ZSWAP is enabled? I guess it doesn't make sense to keep them
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
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.
Thanks! While it's great there's a manual solution, I'd expect there's
a big percent of users who would not know about upcoming enabling of
ZRAM. Should there be some automatic decision? For example, either
disabling ZSWAP or disabling ZRAM? Or perhaps popping up a warning on
upgrade where a user given a choice whether to disable one or another?
> Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is
> enough! The moral of this story is that you can't get away with
> ZRAM without any disk SWAP. You need disk SWAP. And if you have
> SWAP, ZSWAP fits more nicely there as a compressing buffer before
> 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
compression ratios, it can be quite reasonable to go higher than
Thanks! I'll give it a try, will report back.