Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Yet another approach to software suspend
Yet another approach to software suspend
Posted Jul 19, 2007 13:58 UTC (Thu) by i3839 (subscriber, #31386)Parent article: Yet another approach to software suspend
> making it possible to jump from the secondary kernel back into the original kernel.
Which is totally useless for hibernate resume, because there there's no need to do any kexec stuff at resume.
The speed problem is only at suspend/hibernate time, because then the new kernel needs to be started and needs to detect enough hardware to be able to write the image.
This kexec approach seems silly: The old kernel already knows which state needs to be saved and is ready to use the hardware needed for the dump. But the smart thing is that it solves the problem of "how to save the userspace state from userspace without changing that state".
The worrying part is that some people seem to want to use this approach also for the suspend to ram case, where it makes no sense and just complicates and slows down everything.
(Log in to post comments)
Yet another approach to software suspend
Posted Jul 19, 2007 16:38 UTC (Thu) by intgr (subscriber, #39733) [Link]
> there there's no need to do any kexec stuff at resume.As far as I understand it, the "kexec" kernel (which is a misleading name for
it at this point) will load the original kernel state into memory and resume
that.
> some people seem to want to use this approach also for the suspend to ram
> case
Last time I saw Linus speaking about this, it sounded like he'd kill anyone
submitting "disk and RAM suspend" unification patches with an axe.
Yet another approach to software suspend
Posted Jul 19, 2007 23:12 UTC (Thu) by i3839 (subscriber, #31386) [Link]
But the kexec kernel will be the one writing the image and shutting down the machine, after which point it's gone, assuming hibernation. So at "resume" time, the machine just booted up, more or less, and the first kernel that's loaded can be the final one. No place for kexec here.
For the suspend to ram case, switching back is very fast because nothing needs to be done by the "kexec" kernel (in which case it's indeed more a "kvfork" than a "kexec" kernel). But worse, there isn't anything useful to do for the "kexec" kernel in the s2ram case anyway.
> Last time I saw Linus speaking about this, it sounded like he'd kill anyone
> submitting "disk and RAM suspend" unification patches with an axe.
Yeah, I noticed that too, so I'm not overly worried about it happening. ;-)
Sort of ironic that the kexec approach is like the freezer thread on steroids, taking everything much further. The problem is that the stored state should be consistent, there are two ways to achieve that:
1) Prevent that the state changes.
2) Prevent any changes to the state that would cause problems.
The freezer and kexec take the first approach, the latter achieving it arguably much better. Using kexec is tempting because no infrastructure changes are needed or much else. (Maybe it's better to call it the kdump approach instead.) The hard part is to have the required hardware drivers working in the kexec kernel.
To do 2) well more or less all IO needs to be stopped, except for the IO doing the dump image writing. This doesn't seem to be that hard either, but it may add runtime overhead and if you overlook one IO device corruption or less nasty problems can crop up. Advantage is that it should be faster and simpler in the end, though getting there seems like much more work, depending at which level the IO is blocked (if it's done at the driver level then every driver needs to be updated).
Yet another approach to software suspend
Posted Jul 20, 2007 8:36 UTC (Fri) by khim (subscriber, #9252) [Link]
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...
Yet another approach to software suspend
Posted Jul 20, 2007 11:23 UTC (Fri) by Klavs (subscriber, #10563) [Link]
> Are you an idiot or just play one on TV
That is an unnecessary comment, and if we're all lucky, your ridiculous remark will just be ignored.
Pls. do refrain from unnecessary "person attacks" like this in the future - no one wants the LWN comments to become a troll playground.
Yet another approach to software suspend
Posted Jul 21, 2007 0:42 UTC (Sat) by i3839 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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)
One sane unification case
Posted Jul 20, 2007 11:54 UTC (Fri) by farnz (subscriber, #17727) [Link]
There is one interesting unification setup (which can be implemented later, once we've got S2RAM and hibernation working well): hibernate, then (without damaging the hibernate state, so that we can resume again if needed), resume into S2RAM. If we restart running from S2RAM, great, we've just had a nice fast resume. If we lose power, so that we can't resume from S2RAM, ah well, time to restore from hibernate.It's a limited use case, but one that some people could benefit from; I can think of the following times when I'd want it:
- When leaving my desktop alone for an extended period; if power is stable, I want a fast resume. If power goes on me, it'd be nice to still get a resume.
- When my server's UPS tells it that it's low on battery and lacking mains input. If the outage lasts only another 10 minutes, resuming from S2RAM (via USB signalling or similar) is quicker than coming back from hibernate.
- When I'm closing my laptop at the end of the day to travel home; if I've got enough battery to hold me in S2RAM, I'd like the fast resume when I'm next working. If I don't, I'd still prefer resume from disk to rebooting.
As you can see, all of these are unusual use cases, and S2RAM is just an optimization; I'd cope with having to do hibernate for every case.
One sane unification case
Posted Jul 20, 2007 15:00 UTC (Fri) by jond (subscriber, #37669) [Link]
"hibernate, then (without damaging the hibernate state, so that we can resume again if needed), resume into S2RAM."
I guess you mean "suspend into S2RAM" there -- there's a user-space tool "s2both" that does this at the moment, using the existing disk and RAM suspension techniques.
Linux is behind there too.
Posted Jul 20, 2007 20:05 UTC (Fri) by khim (subscriber, #9252) [Link]
What you've described is standard modus of operandi for both Mac OS and Vista... Quite useful approach, yes...