On Tue, Feb 11, 2020 at 3:45 AM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
This discussion is mixing up two different interpretations of
- Supported, as in, "this use case is in scope & is a release criteria"
- Supported, as in, "the functionality works from a technical POV"
Thus since hibernation is declared an unsupported use case, the fact that
it might happen to work from a technical POV is merely good fortune and is
not required to stay that way, even if some people might be using that now.
There is a separate discussion on desktop@ list about the state of
hibernation and whether it's supportable. But a brief summary of
ACPI is a mess of a specification, it's massive and complicated. No
single vendor implements all of it, and possibly not single vendor
implements portions completely correctly and bug free. ACPI power
level S4 is fragile, it doesn't even always work on Windows (or macOS
for that matter) . ACPI power level S3 is apparently becoming more
fragile, noted by increasing user reports where S3 appears to just be
a stub (hardware will enter suspend to RAM, but has variable degrees
of recover from not at all to the display or keyboard don't work).
Hardware vendors, Microsoft, Apple, and Linux kernel developers have
been putting most of their effort into S0 lower power idle because
they don't have to depend on ACPI or (logic board) firmware, and on
faster boot times, where hibernation is a fallback position.
Further, there's this upstream thread about how there must be 50% free
memory in which to create the hibernation image before it can be
written to disk. There's no automatic mechanism for this (yet), the
user has to manually quit enough applications to get memory use below
50%. To me that's not a working hibernation implementation at all on
any platform, to burden the user with esoteric knowledge like this.
IOW, if swap-on-ZRAM benefits core supported use cases, then it can
acceptable to break unsupported use cases even if the latter currently
work at a technical POV. Enabling this kind of trade off to be made is
precisely why it is beneficial to define the scope of a product for
what is supported vs unsupported.
The most aggressive swap use cases might need something more dynamic.
Some might be best off with a small 1G ZRAM device, leaving the vast
majority of RAM for normal usage. Some are better off with quite a lot
more, up to 1:1 with RAM. Testing and upstream docs indicate that
unless you hit an edge case (and they do exist) it's quite sane to
create a ZRAM device 2:1 with RAM. But this is not well enough
understood to give very practical advice to users, let alone some
service that could deal with it dynamically and yet be simple. So the
current idea is to create a ZRAM device sized to 50% RAM, with a cap
at around 2G-4G. That means small memory devices like IoT and ARM will
get what they're already used to, same for VM's with 2G RAM doing
software installs. And then everyone else would see a 2G or 4G device.
Further the idea is to set the priority higher on the ZRAM swap device
so it's used first, and an existing swap partition (or LV) would be
Use cases that benefit from a lot of swap (including the hibernation
use case) can benefit from either the small higher priority
swap-on-ZRAM device while still falling back to swap on a partition,
i.e. two swap devices. Or alternative those folks might prefer zswap
(not related to zram at all) which uses a memory pool to cache a disk
backed swap partition (which must exist). Either way the benefit is
swap thrashing is delayed by a lot by moderating the otherwise abrupt
transition from memory bound work, to IO bound work (swap thrashing).
There is no free lunch here, but it is an optimization that's
A further possibility as it relates to hibernation, is having systemd
activate a swap partition (or even a swapfile) only at hibernation
time. That would block it from being used during normal usage,
preserving it (in effect) for just the hibernation image. There are
some liabilities that need to be explored, and implementation work
hasn't yet begun, so it's a nice idea but a bit vaporware at the