On Fri, Feb 14, 2020 at 9:40 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
> Yes, in my experience it is that easy. If I look into htop before hibernating and I'm over 50% usage (not counting buffers/cache
I'm not familiar with htop. If I run it without options, I see on the
top left my CPUs followed by "Mem" which seems to be the same thing as
/proc/meminfo's "Active(file):" value (if I divide by 1MiB). Is your
50% usage based on this "Mem" reporting?
There isn't a corresponding value in top, the "Mem ... Used" value is
totally different there.
Well, you got me. I'm not too knowledgeable about memory counting on Linux. I simply look at the green portion of the Mem line in htop (should be the same as Mem->Used: value) :-) I always thought it was the same value you can see in `free -h` under "used" column, but now I see it's somewhat different, no idea why. Either way, when the used memory value is /roughly/ above 50%, hibernation consistently fails, if it is below, it consistently works. I never did any experiments to figure out whether the threshold is exactly 50%. But it roughly matched the kernel threads I found (and that you found) saying 50% memory needs to be free in order to make a memory snapshot.
> Feb 14 12:03:28 titan kernel: PM: hibernation exit
> Feb 14 12:03:28 titan systemd-sleep[3424]: Failed to suspend system. System resumed again: Cannot allocate memory
This is a systemd error, without a corresponding kernel message. So is
it really a kernel complaint or problem? Looking at systemd
./src/sleep/sleep.c
220 r = write_state(&f, states);
221 if (r < 0)
222 log_struct_errno(LOG_ERR, r,
223 "MESSAGE_ID="
SD_MESSAGE_SLEEP_STOP_STR,
224 LOG_MESSAGE("Failed to
suspend system. System resumed again: %m"),
225 "SLEEP=%s", arg_verb);
I don't see where "Cannot allocate memory" comes from in systemd, but
in the kernel:
./Documentation/admin-guide/sysctl/vm.rst:864:"fork: Cannot allocate
memory". which is in
https://www.kernel.org/doc/html/v5.5/admin-guide/sysctl/vm.html under
user_reserve_kbytes
Default value on Fedora is
$ cat /proc/sys/vm/user_reserve_kbytes
131072
$ cat /proc/sys/vm/overcommit_memory
0
Hmm. Anyway, I'm not sure what's running out of memory or why. Right
before this, hibernation exit comes from
./power/hibernate.c:781: pr_info("hibernation exit\n");
Looks like it got to here:
732 error = hibernation_snapshot(hibernation_mode ==
HIBERNATION_PLATFORM);
733 if (error || freezer_test_done)
734 goto Free_bitmaps;
*shrug*
It definitely didn't get to writing out the hibernation image.
Well that would match the expectation that it can't create the memory snapshot, no? When I have more than 50% of memory occupied, it can't make another copy of the used memory, and that's why it can't write the hibernation image (compressing it in the process), and instead it returns with an error. This was my assumption and it seems trivial to reproduce (on my machines), but the low-level debugging needs to be done by someone better than me. I'm happy to help with the reproduction steps, if needed, of course.
_______________________________________________ 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
