Re: Hibernation considerations

From: david
Date: Tue Jul 17 2007 - 17:00:56 EST

On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:

On Tuesday, 17 July 2007 22:18, david@xxxxxxx wrote:
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:

On Tuesday, 17 July 2007 19:06, david@xxxxxxx wrote:
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:

On Tuesday, 17 July 2007 17:29, david@xxxxxxx wrote:
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:

On Tuesday, 17 July 2007 16:15, Alan Stern wrote:
On Mon, 16 Jul 2007 david@xxxxxxx wrote:

I agree, it would be good to have a non-ACPI-specific hibernation mode,
something which would look to ACPI like a normal shutdown. But I'm not
so sure this is possible.

why would it not be possible?

I can't think of anything much more frustrating then thinking that I
suspended a system and then discovering that becouse the battery went dead
(a complete power loss) that the system wouldn't boot up properly. to me
this would be a fairly common condition (when I'm mobile I use the machine
until I am out of battery, then stop and it may be a long time (days)
before I can charge the thing up again) this would not be a reliable
suspend as far as I'm concerned.

for suspend-to-ram you have to worry about ACPI states and what you are
doing with them, for suspend-to-disk you can ignore them and completely
power the system off instead.

If the only problem with doing this would be lack of wakeup support
then I'm all for it. There must be a lot of people who would like
their computers to hibernate with power drain as close to 0 as possible
and who don't care about remote wakeup. In fact they might even prefer
not to have wakeup support, so the computer doesn't resume at
unexpected times.

I'm afraid of one thing, though.

If we create a framework without ACPI (well, ACPI needs to be enabled in the
kernel anyway for other reasons, like the ability to suspend to RAM) and then
it turns out that we have to add some ACPI hooks to it, that might be difficult
to do cleanly.

doing suspend-to-ram should be orthoginal to doing hibernate-to-disk. some
people will want both, some won't.

at the moment kexec doesn't work with ACPI, that is a limitation that
should be fixed, but makeing it able to work with ACPI enabled doesn't
mean that it needs to be changed to depend on ACPI and it especially
doesn't mean that it should pick up the limitations of the existing ACPI
based hibernation approaches.

if there is no ACPI on the system it should work, if ther is ACPI on the
system it should still work.

Thus, it seems reasonable to think of the ACPI handling in advance.

but don't become dependant on ACPI.

Not dependent, but with the possibility of ACPI support taken into account.

Arguably you can create a framework that, for example, will not allow the user
to adjust the size of the image, but then adding such a functionality may
require you to change the entire design. Same thing with ACPI.

I would rather avoid such pitfalls, if I could.

Ok, what is it that you think ACPI fundamentally changes in this process?

keep in mind that we are not makeing the assumption that the hardware
will remain powered (even a little bit), or the assumption that nothing
else will run on the hardware (eliminating any possibility that the
hardware is in a known ACPI state)

Well, first, the fact is that _some_ systems _will_ be powered while in
hibernation (the majority of notebooks, for example) and you should assume
that the platform _may_ retain some information accross the hibernation/restore
cycle. In that case you _should_ _not_ trash the information retained by the
platform.

no, systems that remain powered while asleep are a different type of
suspend then ones that don't.

Now, with that in mind, ACPI requires us to make the system enter the S4 sleep
state as a result of the hibernation procedure. In my opinion this may be done
after saving the image, but still this means, for example, that the
image-saving kernel needs to support ACPI.

Next, during the restore, we should first check if the image is present (and
valid) _without_ turning ACPI on (note that this is not done by the current
hibernation code and that leads to strange problems on some systems). Then,
if the image is present (and valid), we should first load it, jump to the
hibernated kernel and _then_ turn ACPI on and execute the _BFS and
_WAK ACPI global methods (again, this is not done by the current code in that
order, which is wrong). Only after that is the hibernated kernel supposed to
continue.

[Please refer to section 15.3 of the 3.0b ACPI spec for details.]

you are starting from the assumption that ACPI S4 mode should be used.

I'm saying that a suspend that uses ACPI S4 mode is fundamentally
different from one that does a power off instead.

It is different, but not fundamentally.

from my point of view the ACPI S4 sleep mode has far more in common with
suspend-to-ram then with the suspend-to-disk that I'm talking about

non-ACPI hibernate

since the box powers off
it uses zero power while suspended
another OS could be run before a resume
hardware can be swapped, suspend image could be sent around the world to be restored on another system.
restore makes no assumptions about the state of the hardware when it is restored
restore is slower (full BIOS boot is required)
should be able to work on just about any hardware (the limit is the ability to initialize the devices)


ACPI suspends

since the box never completely powers off:
a complete power failure breaks the suspend
the OS must remain in control so other uses must be prevented.
hardware must remain in the ACPI state from suspend until restore.
restore can be faster (some initialization may be able to be skipped)
requires ACPI hardware support

under the catagory of ACPI suspends you have

fast suspend-to-ram (stop scheduling, put the CPU to sleep, as long as
the memory keeps getting refreshed)
slow suspend-to-ram (stop scheduling, put as much of the hardware as
possible to sleep, including spinning down disks and other things that
take a while to undo)
suspend-to-disk (stop scheduleing, copy the ram somewhere so that it
doesn't need to be refreshed, put everything into low-power mode)

and there are probably quite a few others as well. but they are all in
the same family in that you have to worry about ACPI states, and they all
have the same restrictions on what can happen between suspend and resume

the non-ACPI hibernate behaves very differently, and for some people (and
I think I am one of them) it will meet their needs better then _any_ of
the ACPI suspends.

OTOH, there are many people who would want the ACPI suspends to be handled
and they don't really care for the power-off-only hibernation.

If you aren't going to support the ACPI hibernation, your framework will be
incomplete and therefore not generally useful.

if you make the framework limited by the ACPI requriement, your framework will not be able to be used in all cases and is therefor incomplete and not generally useful.

see, I can make authoritative sounding declarations too. :-)

I agree that some people want ACPI suspends, but you don't seem to allow the fact that some people don't, and those people don't want to have the ACPI based limits. they _especially_ don't want those limits when it appears as if supporting those limits is what's preventing their much simpler case from working reliably.

I strongly suspect that the majority of users don't care about ACPI, they want to be able to pause and resume their machine. they may want a couple options for how fast the resume is (trading resume speed against how much power the system eats), but the deep sleep modes (suspend-to-disk, hibernate) probably have restore times that are close enough to each other that very few people would care enough to opt for a ACPI S4 mode that won't survive a loss of battery power over a non-ACPI mode that would.

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