Re: Hibernation considerations

On Tuesday, 17 July 2007 22:27, david@xxxxxxx wrote:
On Tue, 17 Jul 2007, Alan Stern wrote:

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

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.

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

Absolutely. This needs to be done in such a way that it will work:

On platforms without ACPI;

On platforms with ACPI where we do a non-ACPI type of shutdown
to whatever extent it is possible (or perhaps an ACPI-aware
shutdown rather than change to S4);

On platforms with ACPI where we do an ACPI-aware transition
to S4.

Rafael, for those of us who aren't thoroughly familiar with all the ins
and outs of the ACPI spec, could you please summarize a list of the
ACPI calls needed in the second and third cases above? Indicate which
ones need to be done from within the original kernel and which should
be done from within a kexec'd hibernation kernel.


there was just a link on slashdot toa primer on the subject of power
management

http://www.techarp.com/showarticle.aspx?artno=420


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? 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.

this is what I'm thinking, but the issue here is that the original kernel
needs to go into suspend-to-ram mode instead of resuming operation. per
the e-mail I got from Ying last night this should not be hard to
implement.

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.

no, user tasks just don't get scheduled during shutdown.

the big problem with the freezer isn't stopping anything from happening,
it's _selectivly_ stopping things.

It's selectively stopping kernel threads, which is just about right. If you
that _this_ is a main problem with the freezer, then think again.

with kexec you don't need to let any portion of the origional kernel or
userspace operate so you don't have a problem.

In fact, the main problem with the freezer is that it is a coarse-grained
solution. Therefore, what I believe we should do is to evolve in the directoin
of more fine-grained solutions and gradually phase out the freezer.

The kexec-based approach is an attempt to replace one coarse-grained solution
(the freezer) with even more coarse-grained solution (stopping the entire
kernel with everything), which IMO doesn't address the main problem.

Greetings,
Rafael


--
"Premature optimization is the root of all evil." - Donald Knuth
-
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/

Relevant Pages