On Tue, Aug 20, 2019 at 2:15 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mo, 19.08.19 13:58, Chris Murphy (lists(a)colorremedies.com) wrote:
> I'm skeptical as well. But to further explore this:
> 1. Does the kernel know better than to write a hibernation image (all
> or part) to a /dev/zram device? e.g. a system with: 8GiB RAM, 8GiB
> swap on ZRAM, 8GiB swap partition. We can use swap priority to use the
> ZRAM device first, and conventional swap partition second. If the
> user, today, were to hibernate, what happens?
Usespace takes care of this. It tells the kernel which swap device to
hibernate to and it nowadays understands that zswap is not a
candidate, and picks the largest swap with the highes prio these days:
For what it's worth, swap on /dev/zram is a totally different thing than zswap.
/dev/zram is just a compressed RAM disk. You can configure a size, but
it only consumes memory as it actually gets used, dynamic allocation.
This can be used for swap standalone, no conventional disk based swap
partition is needed. But if there is one, and it's set to a lower
priority than swap on /dev/zram, then it has the effect of spilling
over (but spill over is uncompressed).
zswap basically always compresses all of swap, with a predefined size
memory pool "cache", and requires a conventional disk based swap
partition as the spill over. Spill over is also compressed.
They superficially sound very similar but the strategies are different
on the details. I've been using both strategies (separately), but have
the most experience with zswap even though above I was referring to
swap on a ZRAM device. I know, so many Z's. But gist is, I can't
really discern any differences from a user point of view.
Zwap uses just a few kernel parameters to set it up. Whereas with swap
on zram, it requires a service unit file to setup the block device,
mkswap, and then swapon.
The swap on ZRAM thing is further complicated by multiple
implementations, and the preferred systemd zram-generator is
IoT folks are using swap on ZRAM now, via the Fedora zram package
(systemd unit file to set everything up). Anaconda folks have their
own built-in swap on ZRAM setup that runs on low memory systems when
anaconda is launched. This happens on both Fedora netinstalls and
LiveOS. And it makes sense for those use cases where a disk based swap
partition doesn't exist, and maybe shouldn't.
Whereas for servers and workstations, zswap is well suited, as they're
perhaps more likely to have a conventional swap partition and have use
cases where spillover is likely.
So why not zswap? Well, kernel documentation shows it as being
experimental still, but upstream considers it stable enough for
production use using zbud allocator now, and z3fold allocator by the
end of the summer they think.