4

After booting up my computer after hibernation (suspend to disk), my desktop is unresponsive for up to 15 minutes. I've found that the slowness is caused by the fact that all running applications seem to be swapped out to disk. For example, 3 GB of RAM may be in use when I suspend to disk. After resuming from hibernation, RAM usage is low (500 MB or so) and slowly everything will start to get swapped back into RAM. The problem does not occur with sleep (suspend to ram).

Is there a problem with my setup (swap partition size, BIOS), or is this simply the way hibernation works in Linux? This answer seems to suggest that TuxOnIce may improve matters; is that possible?

I'm running Arch Linux on a Toshiba Satellite L300-2CP with 4 GB of RAM and a 4 GB swap partition.

EDIT: TuxOnIce (using the linux-pf kernel) indeed makes a huge difference, and basically solves the problem for me. I would find it hard to believe that what I was experiencing with the standard kernel (swsusp) hibernation is normal, however...

EDIT 2: Of course TuxOnIce hangs now and then during hibernation.

Community
  • 1
Brecht Machiels
  • 248
  • Irrelevant comments removed. – terdon Jul 16 '14 at 15:19
  • So... what is your question at this point? Are you wondering if this is normal for the in-kernel hibernate code? Or are you looking to troubleshoot the TuxOnIce hangs? Or something else? – derobert Jul 16 '14 at 16:04
  • @derobert I won't be putting more time into this for the moment, but I suppose the question might be useful for others. – Brecht Machiels Jul 16 '14 at 19:34

2 Answers2

1

You should check your swappiness value. Usually it is left at 60. It should be 10 or 15:

cat /proc/sys/vm/swappiness

You can change it on the fly with

sudo bash -c "echo -e 10 > /proc/sys/vm/swappiness"

and make it stick with

sudo bash -c "echo 'vm.swappiness = 15' >> /etc/sysctl.conf"

More information about swappiness can be found here: https://help.ubuntu.com/community/SwapFaq.

Reinaert Albrecht
  • 11
  • I've been searching for a long time for the answer to being stuck at low frequency after a resume. Finally, this answer works for me, and not sure why. Strangely, changing the swappiness allowed me to change the CPU frequency (scaling_max_freq) back to the normal value (it was permanently stuck at 800 MHz). – axel22 Apr 17 '17 at 02:01
0

You might run a command such as /sbin/hdparm -t /dev/sda1 as root to try to see if there is some problem with your disk read speed.  You might experiment with different values in the file /sys/power/image_size, which affects the bytes allocated for the image when suspending to disk.

Greg Marks
  • 1,811