I'm a big fan of Linux's hibernation support, which works extremely well on all the (admittedly slightly older) hardware I've tried it on. I highly prefer it to full shutdown and power up.
There's one thing about hibernation that's bugged me for a while, though: a hibernated system is always sluggish and unresponsive immediately after having been resumed. It's not snappy immediately after power on. This is exacerbated by old hardware, but happens on newer systems to a slightly notable extent too.
This seems to be because the kernel only swaps the pages critically necessary for [kernel-level] operation back into working memory, restores the kernel's base working state, and lets userspace just churn for a while as various processes swap the pages they need back into RAM under their own steam.
This does not work very well in practice, as the system initially functions as though some large process had forced everything to fully swap to disk. Whatever was on the screen will swap back in pretty quickly, but switch to another process and you'll be waiting a couple seconds as it swaps back into memory too. On older hardware - my case in point is a Core 2 ThinkPad T60 - "a couple seconds" can even wind up being a couple minutes.
I recently realized that this problem has a surprisingly simple solution, after thinking about it for a bit: take note of the tags that label what pages are on disk and in RAM, then restore this exact state on resume. Sure, the resume process might take ~10 seconds more, but I don't care - I'd have a snappy system.
I was wondering if there are any obscure kernel compile options that enable such functionality, or some configuration I can set up that would approximate this behavior?
NOTE: I do not consider swapoff -a; swapon -a a viable solution; the moment the suspended userspace is reanimated, all loaded processes are attempting to execute code and fighting to swap themselves back into RAM, causing massive disk I/O. Attempting to destroy the swap area would only add to the hurricane, and would actually take longer to complete than if the kernel resumed all of RAM before reanimating userspace.
