On Tue, Feb 11, 2020 at 3:45 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > This discussion is mixing up two different interpretations of meaning > of "supported". > > - Supported, as in, "this use case is in scope & is a release criteria" > > vs > > - 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 that: 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. https://lore.kernel.org/linux-mm/CAA25o9RSWPX8L3s=r6A+4oSdQyvGfWZ1bhKfGvSo5nN-X58HQA@xxxxxxxxxxxxxx/ > IOW, if swap-on-ZRAM benefits core supported use cases, then it can be > 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 used second. 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 noticeable. 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 moment. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
