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

[Alon Bar-Lev <alon.barlev@gmail.com>]

Kyle Moffett wrote:
> On Feb 11, 2006, at 11:36, Jan Merka wrote:

>> I strongly disagree. I got suspend-to-RAM to work but its utility is
>> seriously limited by battery capacity. For example, on my laptop (Sony
>> VGN-B100B) with 1.5GB of RAM, a fully charged battery is drained in
>> about 18 hours if the laptop was suspended to RAM.
> 
> Ick, that's kind of sucky hardware then.  My PowerBook with 1GB RAM
> easily gets a week of sleep time off a fully charged battery; I don't
> think I've rebooted it _once_ in the last 2 months, I just leave it
> sleeping in my bag the whole time.  Sony must be doing something wrong,
> because there's easily enough power in a single battery to keep RAM
> refreshed for a _long_ time.
> 
>> Yes, for a few hours suspend-to-RAM is convenient but suspend-to-disk
>> is _reliable_ and _safe_.
> 
> As to the safety issue, I have my Apple Powerbook configured to suspend
> to RAM, and if it gets critically low on battery I have the firmware set
> to resume it automatically and my scripts shut it down so I don't lose
> data.  Suspend-to-RAM when implemented properly _is_ reliable and safe,
> but it seems like a lot of hardware manufacturers get it wrong.
> 

Hello,

I don't understand how a fundamental (good) debate of how
suspend to disk should be implemented in kernel, changed
into this one.

I don't care what Linus said... Suspend-to-disk is more
complicated than suspend-to-RAM. It is more complicated
since it provides more features. Suspend-to-RAM only stores
state, where Suspend-to-disk need to store the state
somewhere thus changing the initial state.

There is a long list of features available at
http://wiki.suspend2.net/FeatureUserRegister, which cannot
be provided using suspend-to-RAM, examples:
1. Store state on files - this allow you to resume your
machine into a different OS.
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).
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.

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

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.

Best Regards,
Alon Bar-Lev.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/