On Thu, Feb 20, 2020 at 10:33 AM Kamil Paral <kparal(a)redhat.com> wrote:
On Wed, Feb 19, 2020 at 10:13 PM Chris Murphy <lists(a)colorremedies.com> wrote:
>
> My test: Fedora Workstation 31, laptop with 8G RAM, 8G swap partition,
> fill up memory using Firefox tabs pointed to various websites, and
> then I followed [1] to issue two commands:
>
> # echo reboot > /sys/power/disk
> # echo disk > /sys/power/state
>
> I experience twice as many failures as successes. Curiously, the
> successes show pageout does happen. Before hibernate there is no swap
> in-use, but after resume ~2GiB swap is in-use and RAM usage is about
> 50%.
Sigh. Turns out this is "my" mistake. 🤦 Hibernation apparently gets affected by
sysctl value vm.swappiness, in my case vm.swappiness=0. When the value is zero, the
hibernation never swaps out the extra memory over 50% and therefore can't hibernate.
When I set it to any positive value (including 1), it works as you described. And all
those people on kernel mailing lists probably also used vm.swappiness=0 and didn't
realize. This might even be a kernel bug, because the documentation doesn't specify
this should affect hibernation behavior, and I'd expect it _should_ affect only live
system usage and not hibernation. But I can't really tell.
I'm sorry for having confused up this discussion :-/
Nope, it's a major clue! This comes up all the time with performance
complaints about swap, oh hey throw this vm.swappiness=0 spaghetti at
the wall. It's entirely plausible this is the origin of this 50%
business. I'll ask about it on linux-mm@. And I think you're correct
to point out that this needs to be a documented consequence of using
this value.
But how in the world did you get suspicious of your custom
vm.swappiness value? :D
In case it's interesting, my testing approach was to open up
gimp, open a picture and enlarge it to 40000 px wide, which takes over 8GB RAM. In total,
I have then about 9GB RAM usage out of total 16GB RAM. Then I issued "systemctl
hibernate". With vm.swappiness=0, there's the out of memory error I already
posted before. I tested that the same occurs when I directly instruct the kernel to
hibernate:
# echo disk > /sys/power/state
-bash: echo: write error: Cannot allocate memory
When I switch to vm.swappiness=1 (or the default 60), I can hibernate just fine, and I
resume with ~6GB RAM in memory and ~3GB in swap. If it is still relevant, I can provide
exact numbers from /proc/meminfo. But I guess now that we see it doesn't affect people
by default, it's no longer that important. This also invalides most of my previous
suggestions about ideal swap size. OTOH I'm very happy that you proved me wrong and I
discovered this, because now I can again hibernate even when my memory is quite full.
I'm vaguely curious. If vm.swappiness=0 and when /proc/meminfo
AnonPages is > 50% of MemTotal that results in this failure.
However...
Even in the idealized VM environment, I've had a couple failures just
after hibernation entry where the VM hangs indefinitely and has to be
killed off. I didn't have a serial console setup to see if the problem
can be captured via virsh console.
I think the biggest two sticking points for this issue:
A. Most x86_64 users have hardware with Secure Boot enabled out of the
box; and Secure Boot and hibernation are mutually exclusive for the
foreseeable future.
https://pagure.io/fedora-workstation/issue/121#comment-627418
B. Before any work could progress on application state saving
capability, as an alternative to hibernation, a cultural shift needs
to happen.
https://pagure.io/fedora-workstation/issue/121#comment-627281
Perhaps it's true that wishful thinking about hibernation encourages a
reluctance to admit the application's role in automatically state
saving. But hibernation isn't a data preserving function as much as
it's a convenience. It can't save your data if hibernation fails entry
or resume. It can't save your data with Secure Boot on. It can't save
your data in event of a crash or power failure. And it can't save
your data if you forget to save your data.
I think we should have a funeral for hibernation, and symbolically
move on, in order to accept the reality that reliable user data and
application state saving isn't going to happen as a system level
function. Application developers have to do some of this or it isn't
going to happen.
If we have Secure Boot compatible hibernation support in 5 years,
what's achieved? None of the "it can't" listed above are addressed.
Still.
And in everyone's defense, Microsoft and Apple struggled with this for
nearly 20 years before they more or less gave up on the idea, and
their modern apps now do mostly save state.
--
Chris Murphy