2

I am running XUbuntu 16.04 with kernel 4.4.0-116-generic (but the same goes for earlier versions) and 16 GB of RAM. I am using a "traditional" hard drive (no SSD) and my swappiness is 0 (RAM is rarely full).

I have been experiencing the following with hibernation : hibernation proper takes less than 2 minutes, but resuming from it takes much, much more time until the applications are responsive (today it took more that 10 minutes to get to the light-locker prompt).

I do not think this is usable (it takes more time to resume from hibernation than booting to a fresh session and reopening the programs).

How can I improve performance ? Am I the only one experiencing these problems ?

True, memory usage right now is 8.8 GB, but what bugs me is the discrepancy between hibernating and resuming times. I understand from other questions that it may be because during hibernation, the kernel freezes all processes and dump the RAM en bloc to swap, while on resuming it just lets processes ask for their pages in swap.

Is this a valid explanation ? If so, why is it done so, as reading big blocks from a hard drives is faster than random accesses ? Can I configure hibernation to not proceed this way ? The question "Restoring in-memory/swapped page state on resume from hibernation" seems related, but I do not know enough of pages to really understand if what they do ("take note of the tags that label what pages are on disk and in RAM, then restore this exact state on resume") is useful and I also do not know how to do it.

1

I think your experiences are very common for the hibernation aka. suspend-to-disk, especially when using a rotating disk.

From the kernel documentation, there is a workaround mentioned which seems to be related to the idea of the link you have posted. If I got it right, this would just empty the swap at once instead of step by step on resume. But it still has to read all the used swap and might take some time.

Q: After resuming, system is paging heavily, leading to very bad interactivity.

A: Try running

cat /proc/[0-9]/maps | grep / | sed 's:. /:/:' | sort -u | while read file do test -f "$file" && cat "$file" > /dev/null done

after resume. swapoff -a; swapon -a may also be useful.

What you might want to test is suspend-to-ram or suspend-to-both which is pretty good explained in the Arch Wiki. Basically:

  • suspend-to-ram does not power off the computer, but puts it in a power save mode. If battery is depleted the state is lost and might lead to problems
  • suspend-to-both is similar to suspend-to-ram but also saves the state into swap, which makes it possible to resume after battery is depleted

Depending on your environment, how the suspend/hibernate method is initiated you can configure this e.g. in XFCE with the xfce4-power-manager GUI.

  • Thanks ; I tested it for a while and it seems to improve things (I have also been fumbling with kernel boot options relative to my graphics driver and this tends to make X crash less at resuming from hibernation). For the record, I put the script in /lib/systemd/system-sleep. – ysalmon Jul 16 '18 at 9:00
0

After reading the helpful links shared in this thread and trying a few things, below is what worked for me.

By default /sys/power/image_size is set to 2/5 of RAM. My system RAM is 12 Gb and swap file size is 8Gb. In this case /sys/power/image_size was around 5 Gb.

When hibernating, if memory usage was above this limit, the system took a long time to resume. On increasing /sys/power/image_size to 8 Gb (swap memory size), resume time was much improved!

The kernel documentation says that its safe to increase /sys/power/image_size. The default limit of 2/5 of system RAM looks to be too low.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.