On Fri, Jun 5, 2020 at 1:38 PM Igor Raits
On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote:
> writing this
> email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where
> giving half of
> my RAM to zram would kill my system's performance, if not quickly
> cause OOM.
Either you did not read the page or I misunderstand how zram works. It
will take 3G of your memory and call it a SWAP. With a compression. So
essentially, if the starts will be aligned you will end up with 9G of
memory. Of course, if that is not enough, you can add on top of that
swap on the disk.
That's basically correct. But that 3G swap when full is not free, it
costs 1.5G RAM. It is true that the efficacy of swap-on-zram is not
100% eviction. It's contingent on the compression ratio. If it's 2:1,
the swap-on-zram eviction efficacy is 50%. The memory cost is 1/2 of
the savings. So you save 1/2. If the compression is 3:1 (which I often
see but safer to promote 2:1), 3G /dev/zram0 with full swap costs 1G
RAM, saving 2G. Efficacy is ~67%.
It is super easy to get confused about this, part of which is it seems
like magicsauce, and thus impossible witchcraft. I spent quite a lot
of time wrapping my head around this. And it wasn't hours. It was
days. I won't admit how many days.
Could there be workloads that get close to 1:1 compression? I don't
know. I haven't seen it. A synthetic test filling up anonymous pages
from /dev/urandom should do this. As a workload gets closer to zero
compression, the setup behaves more like noswap. It's not worse than
noswap, but it would be worse than disk based swap. Still, it's way
faster, so you don't see the swap thrashing. I think such a contrived
test could be worth doing just to understand what happens in practice,
not just in theory.
And also? In a year? No kernel panics. So this code is rather robust.
The manifestations will be in user space.
And I've also tested this with and without earlyoom, for many months
each. And have run webkitgtk compile while giving Firefox 80 tabs. And
it is possible with a zram device set to 100% RAM to get into a kind
of nutty CPU/memory based thrashing that doesn't end for a long time -
which is no different than the same set up with disk based swap,
except it lasts even longer to oom and is IO bound.
So far, the worst case is that it doesn't make things better. I
haven't yet seen it make things worse. But they probably exist,
they're just edge cases. And for those workloads, zswap is likely a
better way to spill over onto a disk based swap partition, while still
getting the benefits of a memory cache.
Another likely bad case, is simply overcommitting the system, by
making it do something it flat out has insufficient resources for. We
know the kernel lacks use space interactivity guarantees. This problem
is part of on-going cgroupsv2 resource control to isolate processes
that are essentially runaway, and we'll see more of that work in the
near future too, both GNOME and KDE.