3

Is anybody trying to use hibernation under Linux (with a HDD), or am I the only one ?

Is anybody satisfied with how it works, or am I the only one where thawing takes 20 to 30 minutes before the system is responsive again ?

I typically use 10 GB of RAM (out of 16). My HDD speed is roughly 100 MB/s, so it should take roughly 1 minute and 40 seconds to write/read the whole content of the RAM to/from the HDD. And indeed, it takes only 2 minutes to go from clicking on the Hibernate button to system powering down. The system looks like it is under stress :

Memory and CPU usage after thawing

What I still cannot fathom is why it takes 20 to 30 minutes to get back to a responsive system on thawing. Everything (including the kernel documentation) looks like the kernel just reads back to RAM the minimum amount of data to get it running, and lets userspace processes swap in from the swap partition in a disorderly fashion.

This would explain the duration of the whole thing (random reads from the HDD instead of sequential) but also why many processes will timeout : Firefox and Thunderbird will state that "some script is not responding", the KDE compositor will think the GPU driver is having difficulties and will disable direct rendering, etc. On another computer I have a SSD and this makes things bearable, but it is still dumbfounding that thawing takes more time than hibernating.

I tried to apply workarounds stated in the kernel documentation ; I asked a similar but more narrow question two years ago and the solution given did improve things somewhat but the situation remains appalling.

I do not understand why the process freeze triggered by hibernation is not released until after the RAM has been restored to its pre-hibernation state. Why was is decided that it was not the kernel job to do so ?

How can I manually freeze my processes (with a STOP signal ?) before hibernation, take note of what is in RAM (versus swapped out), restore this data from swap to RAM on thawing, wait for this operation to complete, then unfreeze the processes (with a CONT signal ?).

3
  • I don't have an answer for you. But I think (with respect) this is a matter of perspective. My system has 32GB of RAM and resumes very well and in seconds on an NVMe disk on debian 10 (same with debian 9). And it's luks encrypted too. Admittedly the disk is ~10x faster than a spinning disk, but it also isn't always moving 32GB of data at every resume. I'm not quite sure how you would expect this to be different. Modern processes tend to take up quite a bit of RAM so memory usage is expected to be high. How can you resume without moving memory data back into RAM?
    – Pedro
    May 4, 2020 at 13:31
  • 1
    Yes, I understand this. The root of my astonishment is the discrepancy between hibernation and thawing times, which I (maybe wrongly) attribute to the way thawing is done. It worked much better with TuxOnIce, where the kernel would take care of restoring the RAM before unfreezing. Thawing time was comparable to hibernation time.
    – ysalmon
    May 4, 2020 at 13:54
  • Yes, that's a good point, again I don't have an answer for that. Only suggestion is whether at the time of hibernation, sufficient memory space is already mirrored in swap so doesn't need moving? Guessing.
    – Pedro
    May 4, 2020 at 19:41

0

Your Answer

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

Browse other questions tagged or ask your own question.