On Thu, Feb 13, 2020 at 9:32 AM Kamil Paral <kparal@xxxxxxxxxx> wrote:
>
> If I understood the kernel discussions correctly, currently there's no simple and reliable mechanism to achieve this (move the excess memory to swap).
It's not clear what conditions they expect this to work automatically,
or if they expect some other facility to do it (like memcgroups).
> Windows, AFAIK, pre-allocates the hibernation image and doesn't share it with swap space. It's very inefficient regarding disk size, but it improves reliability, obviously.
hiberfil.sys and pagefile.sys are dynamically sized. The hiberfil.sys
is actually a generic image based on the current kernel and kernel
drives, and is used for both resuming from hibernation as well as fast
boot. There's a swapfile.sys that contains saved application state
information, so that apps can quick launch. It's a bit different
implementation on macOS, but analogous functionality.
If hibernation innovation isn't going anywhere on linux, including no
plan to have a Secure Boot compatible implementation of hibernation -
it's not long term sustainable anyway. And maybe then the glib, glibc,
and desktop folks, can have a serious discussion about how to make it
possible or easier for applications to save state.
> On my parents'/wife's laptop:
> * This is the most difficult use case. They can't and will not think about battery level and how suspend works when closing the laptop lid. They expect the system to behave intelligently. If they come back to the laptop in a few days and it's drained to 0% so that it won't even turn on and all the progress in opened applications has been lost, that's a big failure. They don't consider it their fault ("I should have powered it off instead"), but the system fault. After all, this situation doesn't happen on Windows. For these regular users, I believe that hybrid sleep is a necessity. Every time I install Linux to a new person, I have to note that they need to be much more careful about power management and using suspend.
And I advocate for their position completely. It's not their fault.
The present functionality is inadequate.
But also, Secure Boot is thus far considered a higher order necessity
than s2h (suspend-to-hibernate), there's also a release blocking
criterion for SB.
> I somewhat disagree. The --hibernation flag just affects swap size. Larger swap makes it a bit more likely that hibernation will work, yes. But that doesn't mean it wouldn't work even with smaller size swap. The resume= parameter is required in all cases, whether you target a system that has large swap or medium swap size by default. Also, don't forget these are just default values, the users can change them during partitioning. It would be sad if the user intentionally configured large swap because she knows she wants to hibernate, and it wouldn't work just because the resume= parameter was missing, right? If some edition wants to prevent hibernation (that alone sounds like a bad idea), they can do it better by not offering the GUI option, or in the extreme case by somehow overriding "systemctl hibernate" functionality (let's not do that). If you allow to hibernate but break the resume (by omitting resume=), then the user just have lost some data.
I mean insofar as default/automatic partitioning, where the tentative
idea is, no swap partition, and use swap-on-ZRAM instead. But if that
seems dramatic, it's effectively the case already with UEFI Secure
Boot systems - the resume parameter is pointless, these users get a
power off when the battery reaches a low threshold. That's data loss.
Right? It's long term not sustainable, in my view, to just keep
ignoring both the lack of hibernation support in any meaningful way,
and also ignoring user's data being tossed on a poweroff.
I know user data loss upon battery low threshold does not happen on
Windows, macOS, and Chromebooks. Out of the box it's preserved.
> Yes, and I have no objections to lowering the default swap size (and thus making hibernation very unlikely to work) for these very reasons. But I'd like to keep it "functional" (except hardware/firmware issues) out of the box if the user decides to create a larger swap during installation (for this use case or some other).
If we're not going to take hibernation functionality seriously anyway,
I question carving out so much space from people's systems by default.
I have no complaint about custom partitioning making a swap partition
by default at 1:1 ratio or whatever is discovered to be most reliable
without being wasteful, and also setting a resume parameter.
--
Chris Murphy
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-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/desktop@xxxxxxxxxxxxxxxxxxxxxxx
