What makes TuxOnIce work so great ?

[ysalmon]

Hi, strange question, maybe not relevant here but I have been experiencing for years a problem with the regular hibernation process (which people cannot seem to pinpoint and solve) that TOI does not exhibit and I am trying to understand what TOI does (or does not) which improves things there.

With the regular hibernation cycle, after thawing, processes are irresponsive for minutes, several more than 10 minutes (especially Firefox). It appears that at the thawing point, much of these processes' memory is in the swap partition, and the time spent is just to push it back to RAM (which for Firefox means several GB). Which is very difficult to understand to me as things were in RAM at the hibernation point (and I have plenty of RAM so swap basically only is used to hibernate as swapiness is set to 0).

And, as I said, hibernating with TOI does not cause this behaviour. I am very, very thankful for this.

How do you achieve this miracle ? Where should I point the maintainers of regular hibernation to ?

[joostheijkoop]

I have a similar symptom with regular hibernation. It only unswaps the minimal needed to have the system to resume and then allows the OS to resume again. Though this is somewhat mitigated by the very fast SSD I use, this is nowhere near the performance I would expect. I have switched to Uswsusp to allow for some compression (though I don't notice a significant difference), but resuming is still terribly slow, due to unswapping being extremely slow once the system is operational again. If I force the swap to be unswapped with the swapoff command it takes >20 min. to unswap the ~16G in swap to RAM. The SSD should be able to achieve read speeds of 1.5GB/s, but swapoff seems to be incapable to read at a higher rate than of few megabytes per second.

I use to use TuxOnIce, because it is orders of magnitude faster at resuming, but sadly it can't deal with an image of > 16GB

[joostheijkoop]

TuxOnIce seems to bypass the regular swap machinery problem by reading the full image as one continuous block from disc achieving >1.5GB net read speed (it also decompresses making it faster than what a raw read would achieve), before it allows to OS to resume.

[ManuelKrause]

I also tried to investigate the really slow recovery of in-kernel hibernation, at the times when @NigelCunningham hadn't kept TOI up-to-date. Especially the >10min of Firefox getting usable again after resume were so annoying. This is around 2* longer than the time to reboot, start FF and reload all my present ~100 tabs. I haven't found many resources that reference this issue, one of them may be https://bugzilla.kernel.org/show_bug.cgi?id=97201 (now closed). But the approach there doesn't solve it completely.

I was glad for your explanations but want to read @NigelCunningham 's answer as he's the developer. Mainly I can't understand why TOI's superior (bypass?) technique hasn't found a way into in-kernel hibernation.

EDIT: With the current TOI at kernel 4.13.6, suspending 8G RAM to swap via TOI takes ~1min and resuming some more seconds -- but then everything is usable at once (when TOI behaved well ^^).

[NigelCunningham]

Hi guys.

Sorry for the slow response.

The in-kernel hibernation seeks to free as much memory as it can before writing the remainder to swap. It has a hard limit of 1/2 of memory.

TuxOnIce tries not to free memory and write the whole image to swap. It has also been designed from the ground up to use multithreading as much as possible so as to work as quickly as possible.

It hasn't found its way into mainline for a number of reasons.

Pavel Machek got a very early version of the hibernation code merged before or just around the time I came on the scene (2002 IIRC). From there, the codebase has only diverged.

When I did the redesign I mentioned above, I did so not just thinking of multithreading but also seeking to make it modular enough to support different transformations (compression and encryption), storage options (network / swap / file...) and UI (not just the progress bars we now use). I was also thinking of future cluster support. When the code was reviewed with a view to merging, the reviewers didn't have all these things in mind and didn't see the need for the design. That didn't help.

Lastly, they really wanted to take the existing in-kernel implementation and make incremental improvements to it. That would be incredibly difficult (imagine trying to rebuild your bicycle into a car while having a usable vehicle at every step). I did make an attempt at providing some incremental patches but the review process was ... unresponsive as far as I recall now.