On Thu, Feb 20, 2020 at 10:33 AM Kamil Paral <kparal@xxxxxxxxxx> wrote: > > On Wed, Feb 19, 2020 at 10:13 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ 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
