KSP, Linux, swap & hibernate

[Laie]

So, I like hibernate (suspend-to-disk). However, it doesn't play nicely with KSP:

When I log back in, KSP is still there, but barely responding. By all appearences, it is still mostly on disk and data is being pulled into RAM "as needed". Trying to work around the issue by doing a swapoff/swapon, I find that swapoff takes about ten minutes (varying from case to case, I've seen everything between 6 and 15 minutes). Data rate from disk is low, often on the order of 1MB/s, but one CPU is fully maxed out.

Even better: if I kill KSP before or during swapoff, the swap clears much faster. It still hogs one CPU, but only for 90-120 seconds. Well, it's not surprising that discarding data is much easier than sorting it out, but frankly, I'd have expected the disk to be the bottleneck in either case.

By comparison, the act of suspending to disk works very quickly. It pretty much has to be a single contigouos write in order to finish as fast as it does.

What is going on here, why is it so CPU-intensive to get the data back from disk?

[rtxoff]

I guess it's because the the wake up process is entirely controlled by the firmware in the motherboard and that one often doesn't use the full speed of the interfaces for compatibility reasons. Also it might take some time until all the peripherals are back online, there might be an intended pause until all of them back to nominal. Additionally it might be a bit tricky to get the processor into the exact same state it was before the hibernation. This all takes more time i guess then just writing their actual states to the disk.

[LordFerret]

When you hibernate in Linux, the entire contents of memory are swapped out as an image and then the machine and all its services are shut down; On restart, the system boots, sees the image in swap and loads it and executes from there. When you suspend, everything is left in memory and the machine (cpu and memory) goes into a low power state, with the hard drives, display, and other peripherals being powered off; On restore, the power state is brought back up (cpu and memory) and hard drives and display and such are re-enabled.

According to the Debian Wiki, there is an alternative for the slow recovery from hibernation; And that is to suspend first, then hibernate. You can read more about it here.

[Laie]

When you hibernate [...] When you suspend, [...]

That's why I like the terms "suspend-to-disk" and "suspend-to-ram", which are usually well understood regardless of what branding one is used to.

According to the Debian Wiki, there is an alternative for the slow recovery from hibernation; And that is to suspend first, then hibernate. You can read more about it here.

(reading, following links, reading some more) As I understand it, this saves time on the way down: suspend-to-ram, put it in your pocket, and if you don't use it within a configurable time, it will suspend to disk.

When you hibernate in Linux, the entire contents of memory are swapped out as an image and then the machine and all its services are shut down; On restart, the system boots, sees the image in swap and loads it and executes from there.

This pretty much sums up all I know about the process. I'd have expected that writing and reading should take about the same amount of time, and that the system won't become available until memory has been fully restored from disk. Both assumptions are obviously wrong, but I don't know why.

Incidentally, on windows, it's the other way 'round: the process of suspending to disk takes friggin' ages, but restore happens quickly and completely. Linux also restores quickly, but unlike windows, the running applications aren't fully useable: they're apparently being pulled from swap on demand. No matter how long the box has been sitting there showing the password prompt, once I sign on and touch anything, there's a noticable delay until it responds. For a terminal window or a browser tab, the delay is short and easy to ignore. KSP, on the other hand, takes a minute to show any response and will lag horribly for an hour or more. Swapoff really is the only cure; it takes a good while to complete, but once it's done, all is well.

[LordFerret]

I'm not an expert on it, but I will say that I can imagine there is a lot more at play than just swapping a memory image to/from disk during hibernation. If you'll think about it: all of the system services, all those open files/devices and the handles assigned, what memory allocated to who, etc ... when you return from hibernation, all of that must somehow be restored/reinstated into a system coming out of a cold boot - after all, your system was saved in a state with having all such allocations and references.

Unlike Windows, I'd bet you could find more comprehensive documentation as to what actually goes on with Linux hibernation.

- - - Updated - - -

This is a bit dated, but you might want to check it out anyway...

https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

- - - Updated - - -

This is a bit more in-depth; It covers device power managment, suspend, and hibernation. I'm about to read through it myself. Enjoy.

http://lxr.free-electrons.com/source/Documentation/power/devices.txt