Yet another approach to software suspend [LWN.net]

Yet another approach to software suspend

Posted Jul 20, 2007 8:36 UTC (Fri) by khim (subscriber, #9252)
In reply to: Yet another approach to software suspend by i3839
Parent article: Yet another approach to software suspend

So at "resume" time, the machine just booted up, more or less, and the first kernel that's loaded can be the final one.

Are you an idiot or just play one on TV ? When the kernel boots it detects all devices anew. The structures will be put in different place in memory, modules will be loaded in different order, etc. A lot of userspace-visible changes. So you must either move all kernel structures in proper positions (it's just 100 times harder then to implement any other hibernate scheme because 99% of kernel code are not ready to see movable structures) or you should fix all userspace programs which interact with kernel in any (i.e. essentially all userspace programs: if the program stores it's own PID somewhere and this PID is used by some kernel-level process in new kernel you are screwed, for example).

Thus the only sensible way to implement wake-up is to restore old kernel in the same state - and after that you need some way to return to that restored kernel. From the perspective of this restored kernel currently active kernel was kexec'ed (even if it's totally different kernel in reality)... Thus you need a way to jump from the secondary kernel back into the original kernel. Hibernate without wake-up is not very useful, really...

(Log in to post comments)

Yet another approach to software suspend

Posted Jul 21, 2007 0:42 UTC (Sat) by i3839 (guest, #31386) [Link]

I think you misunderstand me. With "machine bootup" I meant the hardware, I didn't mean that the kernel does a regular bootup.

The topic was returning from the kexec kernel, and I said it's not needed. Maybe you're right that doing a kexec is needed to cleanly restore the old kernel state, as doing it from the first kernel loaded is too ugly, but I still don't see any reason why there's a need to return from the kexeced kernel back to the original one. Why not just kexec to the restored, original kernel? (No matter to which point exactly.)

Yet another approach to software suspend

Posted Jul 21, 2007 0:49 UTC (Sat) by i3839 (guest, #31386) [Link]

(It makes going to s2ram after the image dump possible, then jumping back is required indeed. But not for plain hibernate.)

Yet another approach to software suspend

Posted Jul 21, 2007 18:48 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]

there is contradictory information about how much work needs to be done for the restore

the current restore functions assume that all the hardware has been put into ACPI low-power mode or the restore image may not work

so the two options right now seem to be
enhance this mode
use kexec to do a kernel shuffle (boot one kernel, kexec to a second kernel that's in the reserved space, then restore the image to the origional location (overwriting the boot kernel) and then kexec into it

the second approach isn't elegant, but doesn't depend on the state of the hardware.

Yet another approach to software suspend

Posted Jul 22, 2007 10:17 UTC (Sun) by i3839 (guest, #31386) [Link]

Why let the kexec kernel do the restore instead of the boot kernel? As I see it there are two cases:

- The normal kernel and the kexec kernels share a kernel image. In this case the boot kernel just needs to allocate mem in the reserved area and kexec to the restored kernel when it's done restoring the image.

- They have two different kernel images. Now the bootup kernel needs to be loaded in the reserved area. Though this can be hard as the bootloader loads the kernel, so yes, in this case doing two kexeces seems simpler, though that would slow down the restore.

It's unclear what the ACPI hibernate mode does, but I guess it lets the bios boot up the machine quicker because it skips some hardware init stuff or something. So you'd want to support this as good as possible anyway, assuming it makes sense, no matter what else you do.

And the kexec approach also depends on the hardware state because the restored image depends on it. Only thing that kexec does well is making a good snapshot, but it doesn't solve the hardware side of it.

(Which could cause complications, because that state might be changed by loading the image.)

So no matter what approach is used (kexec, freezer, ...), 90% of the work will always be the suspend/hibernate/resume/wake-up functions in the drivers. Same for most problems caused.

If the current restore method works fine, why not continue using that?

Yet another approach to software suspend

Posted Jul 22, 2007 22:06 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

Quote:
If the current restore method works fine, why not continue using that?

becouse Rafael is telling everyone that if you completely power off the system the current restore method will not properly restore the box (most things should come up, but things will not be right)