On Tue, Aug 20, 2019 at 2:15 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mo, 19.08.19 13:58, Chris Murphy (lists@colorremedies.com) wrote:
I'm skeptical as well. But to further explore this:
- 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 apparently broken. https://github.com/systemd/zram-generator/issues/4
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.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docume... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docume...
And
https://www.mjmwired.net/kernel/Documentation/blockdev/zram.txt
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. https://bugzilla.kernel.org/show_bug.cgi?id=204563#c6
*shrug*