Software suspend - again

Posted Feb 9, 2006 16:44 UTC (Thu) by bronson (guest, #4806)
In reply to: Software suspend - again by job
Parent article: Software suspend - again

"For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken

There are a number of nontrivial problems with using kexec to suspend a generic kernel. I'm not saying it's impossible, just that the amount of effort required makes it pretty unlikely. Of course, I'd be as happy as anybody to see the suspend problem licked once and for all... This situation is getting embarrasing!

Software suspend - again

Posted Feb 11, 2006 22:14 UTC (Sat) by zblaxell (subscriber, #26385) [Link]

It would seem to me that the problems that need to be solved to adapt kexec to do suspend (suspend-kexec) are all problems that suspend{1,2} have been solved already.

One big hunk of the changes made by the suspend2 patches deal with special cases on work queues, process, and RAM page flags, because suspend{1,2} require the kernel to stay half-alive. Suspend-kexec would stop the entire kernel, with no need to distinguish between one process and another. Crash dumps would already have to do this.

Another big hunk is the suspended kernel image file reader/writer code. In suspend-kexec this would be handled by the newly booted kernel. There would need to be a mechanism where the suspend-kexec kernel can access some of the data structures of the kernel being suspended. OTOH, this is only required for efficiency, to find free pages and avoid writing them to swap, and to know which pages of swap are free so that swap partitions can be reused for suspend image storage. A simpler implementation could get away with using a separate partition and require little interaction (other than read/write page) with the kernel to be suspended at all.

Another big hunk of suspend2 patches is the documentation. 'Nuff said.

The rest of the suspend2 patches are related to restoring time on the CMOS clock, the userspace UI, and various sanity checks during booting.