Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

From: Kyle Moffett
Date: Sun Feb 12 2006 - 06:09:56 EST

On Feb 12, 2006, at 03:51, Alon Bar-Lev wrote:
1. Store state on files

This is not a "feature", it's just something that causes a lot of downsides (chew up disk space, fragment files, add code complexity, etc).

this allow you to resume your machine into a different OS.

This is the "feature". On the other hand, I'm going to argue that this isn't really what we want to be doing for complexity reasons. We want to implement the container and userspace-freeze code described in the virtualization thread, then implement software- suspend-and-resume-into-different-OS as freeze-userspace-container, shutdown. Then you could trivially have different sets of working data/processes, load up multiple sets at once, selectively freeze, etc, with far less kernel complexity.

2. Encrypt state - this allow you to be sure that your data is stored encrypted. (Yes... You can encrypt the memory... but then you need a whole initramfs clone in order to allow the user to specify how he want to encrypt/decrypt).

Why the hell would you even _want_ to encrypt data in RAM? If you have a secure OS install and a passworded screensaver that starts before suspend, then there is _nothing_ an attacker could do to the contents of RAM without hard-booting, which would just completely erase it, or without extremely specialized hardware and expertise. Picking up a machine suspended to RAM is just as secure as picking up one that is on, no more or less.

3. Network resume - this allow you to resume a network machine (Not implemented yet, but cannot be done if
suspend-to-RAM is the sole implementation).

4. Support desktops/servers - this allow you to suspend/resume hardware that is not designed to sleep, in order to minimize downtime on power failure.

This again is covered by the container-freeze stuff being implemented as described above, and is unrelated to the suspend-to-RAM. When I want suspend-to-RAM, I want something that will work instantly with no overhead, so I can close my laptop and have it asleep 2 seconds later, or open it and be able to use it within 2 seconds. That's an extremely different use-case than the above two.

And another fact: Suspend-to-RAM implementation can be derived form suspend-to-disk but not the other way around.

No, the two are _entirely_ independent. Suspend-to-RAM does not need to copy memory at all, whereas suspend-to-disk requires it. That very fact means that suspend-to-RAM is orders of magnitude faster than suspend-to-disk could ever be, especially as RAM gets exponentially larger.

So let's invert the initial "fact"... Suspend-to-RAM is basically for people that don't need the full functionality of suspend-to- disk, after I got suspend-to-disk to work reliably here (suspend2), I *NEVER* use suspend-to-RAM.

No, suspend-to-ram is for people who need instant response times, suspend-to-disk should be an extension or simplification of "Freeze a process tree and all associated system status so we can completely give up the hardware for a while". IMHO, the fact that both are called "suspend" is just due to historical quirk as opposed to any real similarity.

Kyle Moffett

There is no way to make Linux robust with unreliable memory subsystems, sorry. It would be like trying to make a human more robust with an unreliable O2 supply. Memory just has to work.
-- Andi Kleen

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at