Software suspend - again

Posted Feb 9, 2006 22:00 UTC (Thu) by NCunningham (guest, #6457)
Parent article: Software suspend - again

I spent some time with a gleam in my eye yesterday, but the more I thought
about it, the dimmer the gleam got. Here are some of the issues I came up
with, which should be considered in addition to the ones mentioned above.

- At the moment, Suspend2 supports file-backed suspend to ram - we enter
S3 instead of powering down after writing the image. From that state, if
your battery runs out, you do a normal resume, if it doesn't, we just
reread the small portion of memory that was overwritten for the atomic
copy, and then you're resumed. With kexec, this wouldn't be possible.
- It makes things a lot more complicated for users. One of the reasons I
don't like the userspace suspend idea is because it makes it much easier
to break the whole set up. Requiring another kernel would have the same
problems.
- If makes things more complicated programmatically. I doubt that 8MB or
16M would be enough. We need to be able to load all the data to be
atomically restored. That's normally 20-30% of the image, so for a 1GB
image, we need to load up to 512MB, but normally 200-300MB. Unless kexec
does some magic that allows us to access memory outside of the mem= limit
(and I won't deny it's possible!), I'm not sure it can work. Presumably
we'd also need to do some interesting things to get access to the
information in the kernel we're writing, to figure out which pages are LRU
and which aren't (for doing the full image of memory).
- I don't understand kexec much at all yet, but doesn't the switch to the
new kernel take place in real mode? In that case, getting the resume to
happen would require adding extra real mode code to be invoked in place of
the initial boot code, implementing the return to where we left off when
suspending. Not impossible, but it's more complication.

In short, while it sounds nice, and it would be possible, I don't think it
is feasible. As always, I'm willing to be educated that this isn't the
case...

to post comments

Software suspend - again

Posted Feb 11, 2006 12:16 UTC (Sat) by ebiederm (subscriber, #35028) [Link]

Actually the file-backed suspend to ram would work with kexec,
you do the suspend in user space (of the other kernel) then you
suspend the dump kernel to ram. We might want to do a little
trickery so the restore goes back to the primary kernel.

I don't think it is fundamentally more complicated for users but it
would be something that needs looking at.

8M/16M is more than you need that is the kind of size where
you can put a kernel and a glibc based user space in so it is easy.

Well it wouldn't be kexec that let's you access something outside
of mem=limit but /dev/mem.

kexec happens in whatever the kernels native mode is.

The LRU and that information could be an issue. I am not sufficiently
familiar with the swap suspend process to understand what needs to happen.
I think what happens is that you stop all hardware devices and processes
to get a consistent system state. Then you wake up just enough of the
system to save that state?

If that is the case kexec may be useful. Especially when used in the kdump
way kexec is just a nice wrapper around goto. :)