Re: Hibernation considerations
- From: david@xxxxxxx
- Date: Tue, 17 Jul 2007 14:17:35 -0700 (PDT)
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
On Tuesday, 17 July 2007 22:34, david@xxxxxxx wrote:On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
On Tuesday, 17 July 2007 20:32, Alan Stern wrote:
I'm still not entirely clear on how "suspend-to-both" ought to be
handled. Presumably it will start off as a normal hibernation. But
instead of shutting down, wouldn't the kexec'd kernel return to the
original kernel?
No, I think the image-saving kernel should suspend. Then, on resume the
platform will go back to it and it will jump back to the hibernated kernel.
After all, the original kernel knows about all the devices and can put them
into a low-power state, while the kexec'd kernel might not have sufficient
information.
That's correct, but ...
But what about the freezer? The original reason for using kexec was to
avoid the need for the freezer. With no freezer, while the original
kernel is busy powering down its devices, user tasks will be free to
carry out I/O -- which will make the memory snapshot inconsistent with
the on-disk data structures.
... we can't return to the hibernated kernel unless we are going to cancel the
hibernation.
this is where we disagree.
why not? if all that the hibernated kernel does is to suspend-to-ram and
makes no changes to disks or TCP connections anything that it does do
would be lost if power were to fail and you instead did a restore from
disk.
How do you guarantee that no tasks are scheduled when you get back to the
hibernated kernel?
just don't schedule any userspace tasks. all you need to do is to execute the ACPI sleep functions. you normally do that after stopping userspace anyway.
there is only a problem if something takes place that would prevent the
restore-from-disk from working. if this is done in a non-ACPI way that
will work across a power cycle you don't have to worry about the hardware
state not matching anyway.
That's why I think that for the suspend-to-both the image-saving kernel will
need to support the same set of devices as the hibernated kernel.
suspend-to-both doesn't really make sense if the suspend-to-disk portion
is useing the ACPI S4 mode.
Well, not exactly. If your battery runs out of power while you're suspended,
but you have the image saved, it's still better to restore from the image, even
if something may not work correctly after the restore, than to risk a loss of
data.
if things don't work correctly you are still risking the loss of data, the user just doesn't know it.
-if you don't run out of power you will restore-from-ram
if you do run out of power the restore-from-disk won't work either becouse
devices are not in the right ACPI states.
See above.
Greetings,
Rafael
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/
- Follow-Ups:
- Re: Hibernation considerations
- From: Rafael J. Wysocki
- Re: Hibernation considerations
- From: Jeremy Maitin-Shepard
- Re: Hibernation considerations
- References:
- Re: Hibernation considerations
- From: Alan Stern
- Re: Hibernation considerations
- From: Rafael J. Wysocki
- Re: Hibernation considerations
- From: david
- Re: Hibernation considerations
- From: Rafael J. Wysocki
- Re: Hibernation considerations
- Prev by Date: [PATCH 0/6] cpuset aware writeback
- Next by Date: Re: regression: disk error loop (panic?) ide_do_rw_disk-bad:
- Previous by thread: Re: Hibernation considerations
- Next by thread: Re: Hibernation considerations
- Index(es):
Relevant Pages
|
