* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707171416120.3728-100000@iolanthe.rowland.org>
@ 2007-07-17 20:17 ` Rafael J. Wysocki
2007-07-17 20:27 ` david
[not found] ` <200707172217.01890.rjw@sisk.pl>
2 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 20:17 UTC (permalink / raw)
To: Alan Stern
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 20:32, 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.
Sure.
In the third case (ie. transition to S4) we are supposed to do the following:
(1) Upon entering the sleep state, which IMO can be done _after_ the image
has been saved:
* figure out which devices can wake up
* put devices into low power states (wake-up devices are placed in the Dx
states compatible with the wake capability, the others are powered off)
* execute the _PTS global control method
* switch off the nonlocal CPUs (eg. nonboot CPUs on x86)
* execute the _GTS global control method
* set the GPE enable registers corresponding to the wake-up devices)
* make the platform enter S4 (there's a well defined procedure for that)
I think that this should be done by the image-saving kernel.
(2) Upon start-up (by which I mean what happens after the user has pressed
the power button or something like that):
* check if the image is present (and valid) _without_ enabling ACPI (we don't
do that now, but I see no reason for not doing it in the new framework)
* if the image is present (and valid), load it
* turn on ACPI (unless already turned on by the BIOS, that is)
* execute the _BFS global control method
* execute the _WAK global control method
* continue
Here, the first two things should be done by the image-loading kernel, but
the remaining operations have to be carried out by the restored kernel.
In the remaining two cases we generally don't need to bother with the global
ACPI handling.
> 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.
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.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707171416120.3728-100000@iolanthe.rowland.org>
2007-07-17 20:17 ` Rafael J. Wysocki
@ 2007-07-17 20:27 ` david
2007-07-17 21:20 ` Rafael J. Wysocki
2007-07-17 22:38 ` Alan Stern
[not found] ` <200707172217.01890.rjw@sisk.pl>
2 siblings, 2 replies; 110+ messages in thread
From: david @ 2007-07-17 20:27 UTC (permalink / raw)
To: Alan Stern
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
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.
with kexec you don't need to let any portion of the origional kernel or
userspace operate so you don't have a problem.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 20:27 ` david
@ 2007-07-17 21:20 ` Rafael J. Wysocki
2007-07-17 22:38 ` Alan Stern
1 sibling, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:20 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 22:27, david@lang.hm 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
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
2007-07-17 20:27 ` david
2007-07-17 21:20 ` Rafael J. Wysocki
@ 2007-07-17 22:38 ` Alan Stern
1 sibling, 0 replies; 110+ messages in thread
From: Alan Stern @ 2007-07-17 22:38 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tue, 17 Jul 2007 david@lang.hm wrote:
> > 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.
But a user task may be holding a lock which is needed for putting some
device into low-power mode. It can't release that lock if it doesn't
get scheduled.
Alan Stern
^ permalink raw reply [flat|nested] 110+ messages in thread
[parent not found: <200707172217.01890.rjw@sisk.pl>]
* Re: Hibernation considerations
[not found] ` <200707172217.01890.rjw@sisk.pl>
@ 2007-07-17 20:34 ` david
2007-07-17 20:54 ` Jeremy Maitin-Shepard
` (3 more replies)
2007-07-17 20:34 ` Jeremy Maitin-Shepard
[not found] ` <87odiag45q.fsf@jbms.ath.cx>
2 siblings, 4 replies; 110+ messages in thread
From: david @ 2007-07-17 20:34 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
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.
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.
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.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 20:34 ` david
@ 2007-07-17 20:54 ` Jeremy Maitin-Shepard
[not found] ` <87fy3mg39r.fsf@jbms.ath.cx>
` (2 subsequent siblings)
3 siblings, 0 replies; 110+ messages in thread
From: Jeremy Maitin-Shepard @ 2007-07-17 20:54 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list
david@lang.hm writes:
[snip]
> 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.
It would be okay to switch the "hibernated" kernel in order to
e.g. initiate a suspend to ram provided that everything is done
atomically with interrupts off, for instance. It is not clear, though,
that it is possible to suspend to ram atomically like that.
There is also the question of what state the devices will be in when
switching back from the "save image" kernel to the "hibernated" kernel.
[snip]
--
Jeremy Maitin-Shepard
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <87fy3mg39r.fsf@jbms.ath.cx>]
* Re: Hibernation considerations
[not found] ` <87fy3mg39r.fsf@jbms.ath.cx>
@ 2007-07-17 21:04 ` david
0 siblings, 0 replies; 110+ messages in thread
From: david @ 2007-07-17 21:04 UTC (permalink / raw)
To: Jeremy Maitin-Shepard
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list
On Tue, 17 Jul 2007, Jeremy Maitin-Shepard wrote:
> david@lang.hm writes:
>
> [snip]
>
>> 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.
>
> It would be okay to switch the "hibernated" kernel in order to
> e.g. initiate a suspend to ram provided that everything is done
> atomically with interrupts off, for instance. It is not clear, though,
> that it is possible to suspend to ram atomically like that.
why would it neeed to be with interrupts off?
I am arguing that it wouldn't matter if the "hibernated" kernel changed
every bit of ram, as long as it didn't change anything that would be
visable when the ram is overwritten by the saved image.
> There is also the question of what state the devices will be in when
> switching back from the "save image" kernel to the "hibernated" kernel.
yes, this is a key factor.
if the saved image assumes that the hardware is in some ACPI mode instead
of re-initializeing the hardware then the suspend-to-ram operation could
leave them in a different mode.
but if the saved image doesn't make assumptions about the hardware modes
and initializes the hardware then it shouldn't matter.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread
[parent not found: <200707172323.51702.rjw@sisk.pl>]
* Re: Hibernation considerations
[not found] ` <200707172323.51702.rjw@sisk.pl>
@ 2007-07-17 21:17 ` david
2007-07-17 21:27 ` Jeremy Maitin-Shepard
` (2 more replies)
0 siblings, 3 replies; 110+ messages in thread
From: david @ 2007-07-17 21:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
> On Tuesday, 17 July 2007 22:34, david@lang.hm 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
>
>
>
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 21:17 ` david
@ 2007-07-17 21:27 ` Jeremy Maitin-Shepard
2007-07-17 21:43 ` Rafael J. Wysocki
[not found] ` <871wf6g1q1.fsf@jbms.ath.cx>
2 siblings, 0 replies; 110+ messages in thread
From: Jeremy Maitin-Shepard @ 2007-07-17 21:27 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list
david@lang.hm writes:
[snip]
>> 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.
What does "stopping userspace" mean? You already said it does not mean
disabling interrupts. But using the freezer is also not an option,
since the avoidance of that is the main reason for the kexec approach in
the first place.
[snip]
>> 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.
It should be possible on any system to do a hibernate followed by a
shutdown (and then resume properly, without any problems). Thus, for
handling suspend to both, you resume as if the system had been shutdown,
rather than resuming as if the system came from S4.
--
Jeremy Maitin-Shepard
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 21:17 ` david
2007-07-17 21:27 ` Jeremy Maitin-Shepard
@ 2007-07-17 21:43 ` Rafael J. Wysocki
[not found] ` <871wf6g1q1.fsf@jbms.ath.cx>
2 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:43 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 23:17, david@lang.hm wrote:
> On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Tuesday, 17 July 2007 22:34, david@lang.hm 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.
This is plain reinventing the freezer under another guise, sorry. ;-)
> >> 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.
The experience shows that this is not the case. The disks usually work (you
have to initialize them without ACPI anyway to load the image, no?).
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <871wf6g1q1.fsf@jbms.ath.cx>]
* Re: Hibernation considerations
[not found] ` <871wf6g1q1.fsf@jbms.ath.cx>
@ 2007-07-17 21:27 ` david
2007-07-17 21:54 ` Rafael J. Wysocki
2007-07-17 21:45 ` Rafael J. Wysocki
1 sibling, 1 reply; 110+ messages in thread
From: david @ 2007-07-17 21:27 UTC (permalink / raw)
To: Jeremy Maitin-Shepard
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list
On Tue, 17 Jul 2007, Jeremy Maitin-Shepard wrote:
> david@lang.hm writes:
>
> [snip]
>
>>> 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.
>
> What does "stopping userspace" mean? You already said it does not mean
> disabling interrupts. But using the freezer is also not an option,
> since the avoidance of that is the main reason for the kexec approach in
> the first place.
just don't schedule any non-kernel threads.
remember that the normal shutdown/suspend procedure is (from another
related thread)
> >>sys_reboot(LINUX_REBOOT_CMD_KEXEC)
> >> kernel_kexec
> >> kernel_restart_prepare
> >> device_shutdown
> >> machine_shutdown
> >> machine_kexec
I'm just saying that instead of going back to the normal operation of the
kernel you just go directly to the new shutdown routine instead.
> [snip]
>
>>> 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.
>
> It should be possible on any system to do a hibernate followed by a
> shutdown (and then resume properly, without any problems). Thus, for
> handling suspend to both, you resume as if the system had been shutdown,
> rather than resuming as if the system came from S4.
I agree with this, but according to Rafael if the "hibernated" image is
assuming that the devices were put into low-power mode by ACPI and you
boot up instead the system doesn't work right.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 21:27 ` david
@ 2007-07-17 21:54 ` Rafael J. Wysocki
0 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:54 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 23:27, david@lang.hm wrote:
> On Tue, 17 Jul 2007, Jeremy Maitin-Shepard wrote:
>
> > david@lang.hm writes:
> >
> > [snip]
> >
> >>> 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.
> >
> > What does "stopping userspace" mean? You already said it does not mean
> > disabling interrupts. But using the freezer is also not an option,
> > since the avoidance of that is the main reason for the kexec approach in
> > the first place.
>
> just don't schedule any non-kernel threads.
>
> remember that the normal shutdown/suspend procedure is (from another
> related thread)
>
> > >>sys_reboot(LINUX_REBOOT_CMD_KEXEC)
> > >> kernel_kexec
> > >> kernel_restart_prepare
> > >> device_shutdown
> > >> machine_shutdown
> > >> machine_kexec
>
> I'm just saying that instead of going back to the normal operation of the
> kernel you just go directly to the new shutdown routine instead.
>
> > [snip]
> >
> >>> 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.
> >
> > It should be possible on any system to do a hibernate followed by a
> > shutdown (and then resume properly, without any problems). Thus, for
> > handling suspend to both, you resume as if the system had been shutdown,
> > rather than resuming as if the system came from S4.
>
> I agree with this, but according to Rafael if the "hibernated" image is
> assuming that the devices were put into low-power mode by ACPI and you
> boot up instead the system doesn't work right.
That's correct, some devices don't work right, but these are not disks. They
usually are devices closely related to the platform, like the embedded
controller.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] ` <871wf6g1q1.fsf@jbms.ath.cx>
2007-07-17 21:27 ` david
@ 2007-07-17 21:45 ` Rafael J. Wysocki
1 sibling, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:45 UTC (permalink / raw)
To: Jeremy Maitin-Shepard
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list
On Tuesday, 17 July 2007 23:27, Jeremy Maitin-Shepard wrote:
> david@lang.hm writes:
>
> [snip]
>
> >> 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.
>
> What does "stopping userspace" mean? You already said it does not mean
> disabling interrupts. But using the freezer is also not an option,
> since the avoidance of that is the main reason for the kexec approach in
> the first place.
>
> [snip]
>
> >> 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.
>
> It should be possible on any system to do a hibernate followed by a
> shutdown (and then resume properly, without any problems). Thus, for
> handling suspend to both, you resume as if the system had been shutdown,
> rather than resuming as if the system came from S4.
Exactly.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
2007-07-17 20:34 ` david
` (2 preceding siblings ...)
[not found] ` <200707172323.51702.rjw@sisk.pl>
@ 2007-07-17 21:23 ` Rafael J. Wysocki
3 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:23 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 22:34, david@lang.hm 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?
> 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 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
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] ` <200707172217.01890.rjw@sisk.pl>
2007-07-17 20:34 ` david
@ 2007-07-17 20:34 ` Jeremy Maitin-Shepard
[not found] ` <87odiag45q.fsf@jbms.ath.cx>
2 siblings, 0 replies; 110+ messages in thread
From: Jeremy Maitin-Shepard @ 2007-07-17 20:34 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
[snip]
>> 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.
> Sure.
> In the third case (ie. transition to S4) we are supposed to do the following:
> (1) Upon entering the sleep state, which IMO can be done _after_ the image
> has been saved:
I assume you mean "in order to enter the sleep state", rather than "upon
entering the sleep state". I still don't understand what you mean by
"which IMO can be done _after_ the image has been saved"; as far as I
understand, the last step of this process, "make the platform enter S4",
is almost like a shutdown as far as the kernel is concerned (except for
the tiny detail of having to call those special ACPI methods on resume);
consequently, it would seem that nothing can be done after that step.
> * figure out which devices can wake up
> * put devices into low power states (wake-up devices are placed in the Dx
> states compatible with the wake capability, the others are powered off)
> * execute the _PTS global control method
> * switch off the nonlocal CPUs (eg. nonboot CPUs on x86)
> * execute the _GTS global control method
> * set the GPE enable registers corresponding to the wake-up devices)
> * make the platform enter S4 (there's a well defined procedure for that)
> I think that this should be done by the image-saving kernel.
I agree.
> (2) Upon start-up (by which I mean what happens after the user has pressed
> the power button or something like that):
> * check if the image is present (and valid) _without_ enabling ACPI (we don't
> do that now, but I see no reason for not doing it in the new framework)
> * if the image is present (and valid), load it
> * turn on ACPI (unless already turned on by the BIOS, that is)
> * execute the _BFS global control method
> * execute the _WAK global control method
> * continue
> Here, the first two things should be done by the image-loading kernel, but
> the remaining operations have to be carried out by the restored
> kernel.
It doesn't seem like a problem for that to be the case, but out of
curiosity why do those methods need to be executed by the "restored"
kernel, rather than the "image loading" kernel. Do they require some
information from ACPI-related kernel data structures that were populated
by the normal ACPI initialization?
[snip]
> ... we can't return to the hibernated kernel unless we are going to cancel the
> hibernation.
I agree.
> 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.
If all of the devices that the image writing kernel doesn't know about
have already been shut down/powered off by the hibernated kernel, then
does the "image writing" kernel still need to know about them in order
to suspend to RAM properly (i.e. without leaving some devices on wasting
power)?
--
Jeremy Maitin-Shepard
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <87odiag45q.fsf@jbms.ath.cx>]
* Re: Hibernation considerations
[not found] ` <87odiag45q.fsf@jbms.ath.cx>
@ 2007-07-17 20:37 ` david
2007-07-17 20:56 ` Jeremy Maitin-Shepard
` (2 more replies)
2007-07-17 21:11 ` Rafael J. Wysocki
1 sibling, 3 replies; 110+ messages in thread
From: david @ 2007-07-17 20:37 UTC (permalink / raw)
To: Jeremy Maitin-Shepard
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list
On Tue, 17 Jul 2007, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> [snip]
>
>>> 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.
>
>> Sure.
>
>> In the third case (ie. transition to S4) we are supposed to do the following:
>
>> (1) Upon entering the sleep state, which IMO can be done _after_ the image
>> has been saved:
>
> I assume you mean "in order to enter the sleep state", rather than "upon
> entering the sleep state". I still don't understand what you mean by
> "which IMO can be done _after_ the image has been saved"; as far as I
> understand, the last step of this process, "make the platform enter S4",
> is almost like a shutdown as far as the kernel is concerned (except for
> the tiny detail of having to call those special ACPI methods on resume);
> consequently, it would seem that nothing can be done after that step.
>
>> * figure out which devices can wake up
>> * put devices into low power states (wake-up devices are placed in the Dx
>> states compatible with the wake capability, the others are powered off)
this can't be done by the image-saving kernel if that kernel doesn't know
about the device.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 20:37 ` david
@ 2007-07-17 20:56 ` Jeremy Maitin-Shepard
[not found] ` <87bqeag369.fsf@jbms.ath.cx>
2007-07-17 21:24 ` Rafael J. Wysocki
2 siblings, 0 replies; 110+ messages in thread
From: Jeremy Maitin-Shepard @ 2007-07-17 20:56 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list
david@lang.hm writes:
[snip]
>>> * figure out which devices can wake up
>>> * put devices into low power states (wake-up devices are placed in the Dx
>>> states compatible with the wake capability, the others are powered off)
> this can't be done by the image-saving kernel if that kernel doesn't know about
> the device.
The image-saving kernel can be made to know about all of the "wake up"
devices; all other devices should have already been powered off by the
"hibernated" kernel.
--
Jeremy Maitin-Shepard
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <87bqeag369.fsf@jbms.ath.cx>]
* Re: Hibernation considerations
[not found] ` <87bqeag369.fsf@jbms.ath.cx>
@ 2007-07-17 21:06 ` david
[not found] ` <Pine.LNX.4.64.0707171404330.2467@asgard.lang.hm>
1 sibling, 0 replies; 110+ messages in thread
From: david @ 2007-07-17 21:06 UTC (permalink / raw)
To: Jeremy Maitin-Shepard
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list
On Tue, 17 Jul 2007, Jeremy Maitin-Shepard wrote:
> david@lang.hm writes:
>
> [snip]
>
>>>> * figure out which devices can wake up
>>>> * put devices into low power states (wake-up devices are placed in the Dx
>>>> states compatible with the wake capability, the others are powered off)
>
>> this can't be done by the image-saving kernel if that kernel doesn't know about
>> the device.
>
> The image-saving kernel can be made to know about all of the "wake up"
> devices; all other devices should have already been powered off by the
> "hibernated" kernel.
not nessasarily.
for example, you don't want the "hibernated" kernel to spin down your
disks in the general case, but your image-writing kernel may not have
drivers in it to talk to some of the disks. when things are powered
off this just isn't an issue, but if you use S4 mode instead it is.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <Pine.LNX.4.64.0707171404330.2467@asgard.lang.hm>]
* Re: Hibernation considerations
[not found] ` <Pine.LNX.4.64.0707171404330.2467@asgard.lang.hm>
@ 2007-07-17 21:40 ` Rafael J. Wysocki
0 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:40 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 23:06, david@lang.hm wrote:
> On Tue, 17 Jul 2007, Jeremy Maitin-Shepard wrote:
>
> > david@lang.hm writes:
> >
> > [snip]
> >
> >>>> * figure out which devices can wake up
> >>>> * put devices into low power states (wake-up devices are placed in the Dx
> >>>> states compatible with the wake capability, the others are powered off)
> >
> >> this can't be done by the image-saving kernel if that kernel doesn't know about
> >> the device.
> >
> > The image-saving kernel can be made to know about all of the "wake up"
> > devices; all other devices should have already been powered off by the
> > "hibernated" kernel.
>
> not nessasarily.
More than that. The hibernated kernel should not power off any devices,
because that is _wasteful_ (unless, of course, the powering off a device is the
only way to quiesce it).
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
2007-07-17 20:37 ` david
2007-07-17 20:56 ` Jeremy Maitin-Shepard
[not found] ` <87bqeag369.fsf@jbms.ath.cx>
@ 2007-07-17 21:24 ` Rafael J. Wysocki
2 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:24 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 22:37, david@lang.hm wrote:
> On Tue, 17 Jul 2007, Jeremy Maitin-Shepard wrote:
>
> > "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >
> > [snip]
> >
> >>> 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.
> >
> >> Sure.
> >
> >> In the third case (ie. transition to S4) we are supposed to do the following:
> >
> >> (1) Upon entering the sleep state, which IMO can be done _after_ the image
> >> has been saved:
> >
> > I assume you mean "in order to enter the sleep state", rather than "upon
> > entering the sleep state". I still don't understand what you mean by
> > "which IMO can be done _after_ the image has been saved"; as far as I
> > understand, the last step of this process, "make the platform enter S4",
> > is almost like a shutdown as far as the kernel is concerned (except for
> > the tiny detail of having to call those special ACPI methods on resume);
> > consequently, it would seem that nothing can be done after that step.
> >
> >> * figure out which devices can wake up
> >> * put devices into low power states (wake-up devices are placed in the Dx
> >> states compatible with the wake capability, the others are powered off)
>
> this can't be done by the image-saving kernel if that kernel doesn't know
> about the device.
Good observation. :-)
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] ` <87odiag45q.fsf@jbms.ath.cx>
2007-07-17 20:37 ` david
@ 2007-07-17 21:11 ` Rafael J. Wysocki
1 sibling, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 21:11 UTC (permalink / raw)
To: Jeremy Maitin-Shepard
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list
On Tuesday, 17 July 2007 22:34, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> [snip]
>
> >> 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.
>
> > Sure.
>
> > In the third case (ie. transition to S4) we are supposed to do the following:
>
> > (1) Upon entering the sleep state, which IMO can be done _after_ the image
> > has been saved:
>
> I assume you mean "in order to enter the sleep state", rather than "upon
> entering the sleep state".
Yes, that seems to be more accurate.
> I still don't understand what you mean by
> "which IMO can be done _after_ the image has been saved"; as far as I
> understand, the last step of this process, "make the platform enter S4",
> is almost like a shutdown as far as the kernel is concerned (except for
> the tiny detail of having to call those special ACPI methods on resume);
> consequently, it would seem that nothing can be done after that step.
Well, the ACPI spec suggests to save the image somewhere after the devices
have been but into low power states, which is kind of unreasonable. :-)
> > * figure out which devices can wake up
> > * put devices into low power states (wake-up devices are placed in the Dx
> > states compatible with the wake capability, the others are powered off)
> > * execute the _PTS global control method
> > * switch off the nonlocal CPUs (eg. nonboot CPUs on x86)
> > * execute the _GTS global control method
> > * set the GPE enable registers corresponding to the wake-up devices)
> > * make the platform enter S4 (there's a well defined procedure for that)
> > I think that this should be done by the image-saving kernel.
>
> I agree.
>
> > (2) Upon start-up (by which I mean what happens after the user has pressed
> > the power button or something like that):
> > * check if the image is present (and valid) _without_ enabling ACPI (we don't
> > do that now, but I see no reason for not doing it in the new framework)
> > * if the image is present (and valid), load it
> > * turn on ACPI (unless already turned on by the BIOS, that is)
> > * execute the _BFS global control method
> > * execute the _WAK global control method
> > * continue
> > Here, the first two things should be done by the image-loading kernel, but
> > the remaining operations have to be carried out by the restored
> > kernel.
>
> It doesn't seem like a problem for that to be the case, but out of
> curiosity why do those methods need to be executed by the "restored"
> kernel, rather than the "image loading" kernel. Do they require some
> information from ACPI-related kernel data structures that were populated
> by the normal ACPI initialization?
Well, there are some complications. For example, _BFS and _WAK should be
executed with interrupts on (I'm told that the AML interpreter might not work
with interrupts disabled) and the nonboot CPUs should be offline while they
are being executed. Perhaps we should also avoid playing with APICs and
things like that after executing _WAK, so it's better to execute them from the
restored kernel.
> [snip]
>
> > ... we can't return to the hibernated kernel unless we are going to cancel the
> > hibernation.
>
> I agree.
>
> > 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.
>
> If all of the devices that the image writing kernel doesn't know about
> have already been shut down/powered off by the hibernated kernel, then
> does the "image writing" kernel still need to know about them in order
> to suspend to RAM properly (i.e. without leaving some devices on wasting
> power)?
For some devices it may be illegal to leave them powered on while entering
S3.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] <200707151433.34625.rjw@sisk.pl>
@ 2007-07-15 12:51 ` Nigel Cunningham
2007-07-15 12:58 ` Dr. David Alan Gilbert
` (7 subsequent siblings)
8 siblings, 0 replies; 110+ messages in thread
From: Nigel Cunningham @ 2007-07-15 12:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: david, Al Boldi, LKML, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
[-- Attachment #1.1: Type: text/plain, Size: 6039 bytes --]
Hi.
On Sunday 15 July 2007 22:33:32 Rafael J. Wysocki wrote:
> Hi,
>
> Since many alternative approaches to hibernation are now being considered
and
> discussed, I thought it might be a good idea to list some things that in my
not
> so humble opinion should be taken care of by any hibernation framework.
They
> are listed below, not in any particular order, because I think they all are
> important. Still, I might have forgotten something, so everyone with
> experience in implementing hibernation, especially Pavel and Nigel, please
> check if the list is complete.
>
> (1) Filesystems mounted before the hibernation are untouchable
>
> When there's a memory snapshot, either in the form of a hibernation
image,
> or in the form of the "old" kernel and processes available to the "new"
> kexeced kernel responsible for saving their memory, the filesystems
mounted
> before the hibernation should not be accessed, even for reading, because
> that would cause their on-disk state to be inconsistent with the
snapshot
> and might lead to a filesystem corruption.
>
> (2) Swap space in use before the hibernation must be handled with care
>
> If swap space is used for saving the memory snapshot, the
snapshot-saving
> application (or kernel) must be careful enough not to overwrite swap
pages
> that contain valid memory contents stored in there before the
hibernation.
>
> (3) There are memory regions that must not be saved or restored
>
> Some memory regions contain data that shouldn't be overwritten during
the
> restore, because that might lead to the system not working correctly
> afterwards. Also, on some systems there are valid 'struct pages'
> structures that in fact corresond to memory holes and we should not
attempt
> to save those pages.
>
> (4) The user should be able to limit the size of a hibernation image
>
> There are a couple of reasons of that. For example, the storage space
> used for saving the image may be smaller than the entire RAM or the user
> may want the image to be saved quickier.
>
> (5) Hibernation should be transparent from the applications' point of view
>
> Generally, applications should not notice that hibernation took place.
> [Note that I don't regard all processes as applications and I think that
> there may be processes which need to handle the hibernation in a special
> way.] Ideally, for example, if some audio is being played when a
> hibernation starts, the audio player should be able to continue playing
the
> same audio after the restore from the point in which it has been
> interrupted by the hibernation. Also, the CPU affinities and similar
> settings requested by the applications before a hibernation should be
> binding after the restore.
>
> (6) State of devices from before hibernation should be restored, if possible
>
> If possible, during a restore devices should be brought back to the same
> state in which they were before the corresponding hibernation. Of
course
> in some situations it might be impossible to do that (eg. the user
> connected the hibernated system to a different IP subnet and then
> restored), but as a general rule, we should do our best to restore the
> state of devices, which is directly related to point (5) above.
>
> (7) On ACPI systems special platform-related actions have to be carried out
at
> the right points, so that the platform works correctly after the restore
>
> The ACPI specification requires us to invoke some global ACPI methods
> during the hibernation and during the restore. Moreover, the ordering
of
> code related to these ACPI methods may not be arbitrary (eg. some of
> them have to be executed after devices are put into low power states
etc.).
>
> (8) Hibernation and restore should not be too slow
>
> In my opinion, if more than one minute is needed to hibernate the system
> with the help of certain hibernation framework, then this framework is
not
> very useful in practice. It might be useful to perform some special
tasks
> (eg. moving a server to another place without taking it down), but it is
> not very useful, for example, to notebook users.
>
> (9) Hibernation framework should not be too difficult to set up
>
> It follows from my experience that if the users are required to do too
much
> work to set up a hibernation framework, they will not use it as long as
> there are simpler alternatives (some of them will not use hibernation at
> all if it's too difficult to get to work). On the other hand, if the
users
> are provided with a working hibernation framework by their distribution
> and they find it useful, they are not likely to use kernel.org kernels
if
> t's too difficult to replace the distribution kernel with a generic one
due
> to the hibernation framework's requirements.
>
> All of the existing hibernation frameworks have been written with the above
> points in mind and that's why they are what they are. In particular, the
> existence of the tasks freezer, hated by some people to the point of
insanity,
> follows directly from points (1), (4) and (5).
>
> In my opinion any hibernation framework that doesn't take the above
> requirements into account in any way will be a failure. Moreover, the
existing
> frameworks fail to follow some of them too, so I consider all of these
> frameworks as a work in progress. For this reason, I will much more
appreciate
> ideas allowing us to improve the existing frameworks in a more or less
> evolutionary way, then attempts to replace them all with something entirely
> new.
Sounds good to me. Nothing extra occurs immediately.
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
[not found] <200707151433.34625.rjw@sisk.pl>
2007-07-15 12:51 ` Nigel Cunningham
@ 2007-07-15 12:58 ` Dr. David Alan Gilbert
[not found] ` <200707151810.33554.a1426z@gawab.com>
` (6 subsequent siblings)
8 siblings, 0 replies; 110+ messages in thread
From: Dr. David Alan Gilbert @ 2007-07-15 12:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> (5) Hibernation should be transparent from the applications' point of view
>
> Generally, applications should not notice that hibernation took place.
> [Note that I don't regard all processes as applications and I think that
> there may be processes which need to handle the hibernation in a special
> way.] Ideally, for example, if some audio is being played when a
> hibernation starts, the audio player should be able to continue playing the
> same audio after the restore from the point in which it has been
> interrupted by the hibernation. Also, the CPU affinities and similar
That would be _so_ embarrassing in a library; I'd rather the audio
player had the opportunity to consider whether restarting was a good idea.
> (6) State of devices from before hibernation should be restored, if possible
>
> If possible, during a restore devices should be brought back to the same
> state in which they were before the corresponding hibernation. Of course
> in some situations it might be impossible to do that (eg. the user
> connected the hibernated system to a different IP subnet and then
> restored), but as a general rule, we should do our best to restore the
> state of devices, which is directly related to point (5) above.
Or the user unplugs their flash drive after hibernation rather than before.
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the key accross a hibernation; I want to be forced to
reenter the phrase. However I don't know what the best thing
to do to partitions/applications using the luks device is.
2) Some level of debugging needs to be available so that users can
provide something so you can see why something hasn't hibernated
or why (as in the case of this tosh laptop) it still takes power
during hibernation.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <200707151810.33554.a1426z@gawab.com>]
* Re: Hibernation considerations
[not found] ` <200707151810.33554.a1426z@gawab.com>
@ 2007-07-15 15:35 ` jimmy bahuleyan
2007-07-15 16:29 ` Alan Stern
[not found] ` <469A3EB9.8000304@gmail.com>
2 siblings, 0 replies; 110+ messages in thread
From: jimmy bahuleyan @ 2007-07-15 15:35 UTC (permalink / raw)
To: Al Boldi
Cc: david, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
Al Boldi wrote:
>
> This should be the responsibility of the kexec'd hibernating kernel. Note
> though in (6), the normal kernel takes care of preparing devices, then the
> hibernating kernel dumps the image and either calls S4 or S3. On resume
> from S3 it can immediately switch over to the normal kernel, and from S4 the
> known bootup would occur.
>
>> (8) Hibernation and restore should not be too slow
>>
>> In my opinion, if more than one minute is needed to hibernate the
>> system with the help of certain hibernation framework, then this framework
>> is not very useful in practice. It might be useful to perform some
>> special tasks (eg. moving a server to another place without taking it
>> down), but it is not very useful, for example, to notebook users.
>
> The latest hibernating kexec patches boot a kexec'd modular kernel with
> initramfs into crashkernel=16M@16M in less than one second. Switch-back is
> almost instant. Add to this the time required to either store or restore
> the image, and it may be obvious that this approach isn't slower, but maybe
> even faster than the current swsusp.
>
What about (9)? Would it be that a user choosing to build a kernel with
hibernate support gets a additional modular kernel built (which he
should then use for resumption) or he should configure & build the
modular kernel independent of main kernel?
Or will the Linux boot procedure change so that it always goes thru a
modular part followed by kexec (just to be uniform)?
Although the kexec approach seems interesting, the final user-scenario
seems a bit complex (or confusing).
-jb
--
Tact is the art of making a point without making an enemy.
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
[not found] ` <200707151810.33554.a1426z@gawab.com>
2007-07-15 15:35 ` jimmy bahuleyan
@ 2007-07-15 16:29 ` Alan Stern
[not found] ` <469A3EB9.8000304@gmail.com>
2 siblings, 0 replies; 110+ messages in thread
From: Alan Stern @ 2007-07-15 16:29 UTC (permalink / raw)
To: Al Boldi
Cc: david, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Sun, 15 Jul 2007, Al Boldi wrote:
> > If possible, during a restore devices should be brought back to the
> > same state in which they were before the corresponding hibernation. Of
> > course in some situations it might be impossible to do that (eg. the user
> > connected the hibernated system to a different IP subnet and then
> > restored), but as a general rule, we should do our best to restore the
> > state of devices, which is directly related to point (5) above.
>
> This part could easily be handled by the normal kernel before and after
> resume.
I agree with you except for the word "easily". And there are some
things the kernel simply punts on (I'm thinking of the current VGA
font).
> > (7) On ACPI systems special platform-related actions have to be carried
> > out at the right points, so that the platform works correctly after the
> > restore
> >
> > The ACPI specification requires us to invoke some global ACPI methods
> > during the hibernation and during the restore. Moreover, the ordering
> > of code related to these ACPI methods may not be arbitrary (eg. some of
> > them have to be executed after devices are put into low power states
> > etc.).
>
> This should be the responsibility of the kexec'd hibernating kernel. Note
> though in (6), the normal kernel takes care of preparing devices, then the
> hibernating kernel dumps the image and either calls S4 or S3. On resume
> from S3 it can immediately switch over to the normal kernel, and from S4 the
> known bootup would occur.
Is it really that simple? Somehow I doubt it. In order for some
devices to remain available for the kexec'd kernel to use, they cannot
be suspended at the ACPI level. So the kexec'd kernel will have to
handle the ACPI requirements for those devices. Likewise, it would
have to handle the ACPI interactions which need to be done after all
devices are prepared for the transition to S3 or S4.
> > (8) Hibernation and restore should not be too slow
> >
> > In my opinion, if more than one minute is needed to hibernate the
> > system with the help of certain hibernation framework, then this framework
> > is not very useful in practice. It might be useful to perform some
> > special tasks (eg. moving a server to another place without taking it
> > down), but it is not very useful, for example, to notebook users.
>
> The latest hibernating kexec patches boot a kexec'd modular kernel with
> initramfs into crashkernel=16M@16M in less than one second. Switch-back is
> almost instant. Add to this the time required to either store or restore
> the image, and it may be obvious that this approach isn't slower, but maybe
> even faster than the current swsusp.
Does that include the time required for probing PCI buses? On my
desktop system, PCI probing incurs a five-second timeout delay because
of a bug in the BIOS's USB firmware. Don't be so sure that kexec will
always be lightning fast; it is always better to avoid unnecessary
boots.
Alan Stern
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <469A3EB9.8000304@gmail.com>]
* Re: Hibernation considerations
[not found] ` <469A3EB9.8000304@gmail.com>
@ 2007-07-15 17:40 ` Al Boldi
0 siblings, 0 replies; 110+ messages in thread
From: Al Boldi @ 2007-07-15 17:40 UTC (permalink / raw)
To: jimmy bahuleyan
Cc: david, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
jimmy bahuleyan wrote:
> Al Boldi wrote:
> > This should be the responsibility of the kexec'd hibernating kernel.
> > Note though in (6), the normal kernel takes care of preparing devices,
> > then the hibernating kernel dumps the image and either calls S4 or S3.
> > On resume from S3 it can immediately switch over to the normal kernel,
> > and from S4 the known bootup would occur.
> >
> >> (8) Hibernation and restore should not be too slow
> >>
> >> In my opinion, if more than one minute is needed to hibernate the
> >> system with the help of certain hibernation framework, then this
> >> framework is not very useful in practice. It might be useful to
> >> perform some special tasks (eg. moving a server to another place
> >> without taking it down), but it is not very useful, for example, to
> >> notebook users.
> >
> > The latest hibernating kexec patches boot a kexec'd modular kernel with
> > initramfs into crashkernel=16M@16M in less than one second. Switch-back
> > is almost instant. Add to this the time required to either store or
> > restore the image, and it may be obvious that this approach isn't
> > slower, but maybe even faster than the current swsusp.
>
> What about (9)? Would it be that a user choosing to build a kernel with
> hibernate support gets a additional modular kernel built (which he
> should then use for resumption) or he should configure & build the
> modular kernel independent of main kernel?
>
> Or will the Linux boot procedure change so that it always goes thru a
> modular part followed by kexec (just to be uniform)?
>
> Although the kexec approach seems interesting, the final user-scenario
> seems a bit complex (or confusing).
Well, it may sound confusing because it is so unexpectedly simple. I didn't
answer to (9) because from a user pov nothing should change, and everything
should be scriptable such that the user wouldn't even notice the kernel
using a new hibernation approach.
Thanks!
--
Al
^ permalink raw reply [flat|nested] 110+ messages in thread
[parent not found: <469A8515.3080109@gmx.de>]
* Re: Hibernation considerations
[not found] ` <469A8515.3080109@gmx.de>
@ 2007-07-15 19:46 ` david
0 siblings, 0 replies; 110+ messages in thread
From: david @ 2007-07-15 19:46 UTC (permalink / raw)
To: Cornelius Riemenschneider
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Sun, 15 Jul 2007, Cornelius Riemenschneider wrote:
> Hi,
> I think a (10) is needed to be clear:
>
> (10) This depends directly on (9)
> Easy Userinterface for the average user, no one wants to edit several
> files and use a long commandline for a suspend (not all know about
> alias(P)), so keeping the effort to suspend your system low, please.(eg
> for my TuxOnIce i just type hibernate as root/ sudo hibernate as normal
> user and the suspend begin, the rest is automatically done by the
> configuration(for me this is shutting down my wireless interface)
>
> Cornelius Riemenschneider
for both #9 and #10, if there are complex command lines that need to be
used, they can be put into scripts (including things like 'sudo
hibernate')
this doesn't prevent people from useing kernel.org kernels, in fact the
seperate between the main system and what's used for hibernation may make
it easier to change the main kernel (all that you would need is to enable
kexec in your main kernel and 'everything else would just work')
now if you need/want to change out your hibernate kernel you will have to
change the hibernate scripts to tell them to use the new kernel. yes this
is an extra step, but it can still be simple. for that matter, it may be
possible for the distros to agree enough to add 'make install_hibernate'
to the kernel makefiles like they have 'make install' that will just 'do
the right thing' for each particular distro.
makeing things explicit and flexible may require complex command lines to
implement, but nothing says that the user (even a moderatly advanced user)
needs to deal with those command lines directly.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] <200707151433.34625.rjw@sisk.pl>
` (3 preceding siblings ...)
[not found] ` <469A8515.3080109@gmx.de>
@ 2007-07-15 20:13 ` david
[not found] ` <200707160047.28420.rjw@sisk.pl>
` (2 more replies)
2007-07-15 20:35 ` Cornelius Riemenschneider
` (3 subsequent siblings)
8 siblings, 3 replies; 110+ messages in thread
From: david @ 2007-07-15 20:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
> Hi,
>
> Since many alternative approaches to hibernation are now being considered and
> discussed, I thought it might be a good idea to list some things that in my not
> so humble opinion should be taken care of by any hibernation framework. They
> are listed below, not in any particular order, because I think they all are
> important. Still, I might have forgotten something, so everyone with
> experience in implementing hibernation, especially Pavel and Nigel, please
> check if the list is complete.
>
> (1) Filesystems mounted before the hibernation are untouchable
>
> When there's a memory snapshot, either in the form of a hibernation image,
> or in the form of the "old" kernel and processes available to the "new"
> kexeced kernel responsible for saving their memory, the filesystems mounted
> before the hibernation should not be accessed, even for reading, because
> that would cause their on-disk state to be inconsistent with the snapshot
> and might lead to a filesystem corruption.
AFAIK this is only the case with ext3, all other filesystems could be
accessed read-only safely
this is arguably a bug with ext3 (and has been discussed as such), but
right now the ext3 team has decided not to change this bahavior so
hibernate needs to work around it. but don't mistake a work-around for a
single (admittedly very popular) filesystem with a hard and fast
directive.
> (2) Swap space in use before the hibernation must be handled with care
>
> If swap space is used for saving the memory snapshot, the snapshot-saving
> application (or kernel) must be careful enough not to overwrite swap pages
> that contain valid memory contents stored in there before the hibernation.
true, in fact, given that many distros and live-CD's autodetect swap
partitions and consider them fair game, I would argue that the best thing
to do would be to have the main system free up it's swap partitions before
going into hibernation.
however, this could be a decision of the particular hibernate routines.
for the kexec approach the mapping of what swap pages are in use is one
more chunk of data that needs to be assembled and made available through a
defined interface.
> (4) The user should be able to limit the size of a hibernation image
>
> There are a couple of reasons of that. For example, the storage space
> used for saving the image may be smaller than the entire RAM or the user
> may want the image to be saved quickier.
it may make sense for this to be split into hard and soft limits.
if you try to save more then the storage space can hold you cannot
continue, but if you are just a little over the arbatrary size limit that
was set to make things fast you are better off saving things as-is then
punting, going back to the system, trying to free more ram, and trying a
hibernate again.
with the kexec approach the enforcment of these limits is also split into
two sections.
when the hibernate command is given in the main kernel, it's userspace
needs to follow some policy to decide how much (if any) memory to free.
this could be anything from 'none, try and save all caches' to 'anything
you can to minimize the amount of data to be saved, trash all caches' to
something in between like 'try and free up enough memory to get the saved
data below 1G, but save caches beyond that point'
then when the second kernel runs, it's userspace tools get the list of
what memory should be saved that the main kernel handed to it, and then
decides if this is acceptable (probably mostly the hard limits of 'can
this work') and proceeds to save it somewhere.
but since the kexec command and the preporation of the devices can change
the memory, the estimates done by the first kernel's userspace are just
that, estimates.
> (7) On ACPI systems special platform-related actions have to be carried out at
> the right points, so that the platform works correctly after the restore
>
> The ACPI specification requires us to invoke some global ACPI methods
> during the hibernation and during the restore. Moreover, the ordering of
> code related to these ACPI methods may not be arbitrary (eg. some of
> them have to be executed after devices are put into low power states etc.).
for a pure hibernate mode, you will be powering off the box after saving
the suspend image. why are there any special ACPI modes involved?
now, for suspend-to-ram you need to be aware of every possible power
saving option you have and the cost of each of them, and here the ACPI
modes are heavily used.
I think this is mixing suspend and hibernate still.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <200707160047.28420.rjw@sisk.pl>]
* Re: Hibernation considerations
[not found] ` <200707160047.28420.rjw@sisk.pl>
@ 2007-07-15 22:42 ` david
2007-07-15 23:15 ` Alan Stern
` (2 more replies)
0 siblings, 3 replies; 110+ messages in thread
From: david @ 2007-07-15 22:42 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
>>
>>> Hi,
>>>
>>> Since many alternative approaches to hibernation are now being considered and
>>> discussed, I thought it might be a good idea to list some things that in my not
>>> so humble opinion should be taken care of by any hibernation framework. They
>>> are listed below, not in any particular order, because I think they all are
>>> important. Still, I might have forgotten something, so everyone with
>>> experience in implementing hibernation, especially Pavel and Nigel, please
>>> check if the list is complete.
>>>
>>> (1) Filesystems mounted before the hibernation are untouchable
>>>
>>> When there's a memory snapshot, either in the form of a hibernation image,
>>> or in the form of the "old" kernel and processes available to the "new"
>>> kexeced kernel responsible for saving their memory, the filesystems mounted
>>> before the hibernation should not be accessed, even for reading, because
>>> that would cause their on-disk state to be inconsistent with the snapshot
>>> and might lead to a filesystem corruption.
>>
>> AFAIK this is only the case with ext3, all other filesystems could be
>> accessed read-only safely
>>
>> this is arguably a bug with ext3 (and has been discussed as such), but
>> right now the ext3 team has decided not to change this bahavior so
>> hibernate needs to work around it. but don't mistake a work-around for a
>> single (admittedly very popular) filesystem with a hard and fast
>> directive.
>>
>>> (2) Swap space in use before the hibernation must be handled with care
>>>
>>> If swap space is used for saving the memory snapshot, the snapshot-saving
>>> application (or kernel) must be careful enough not to overwrite swap pages
>>> that contain valid memory contents stored in there before the hibernation.
>>
>> true, in fact, given that many distros and live-CD's autodetect swap
>> partitions and consider them fair game, I would argue that the best thing
>> to do would be to have the main system free up it's swap partitions before
>> going into hibernation.
>>
>> however, this could be a decision of the particular hibernate routines.
>>
>> for the kexec approach the mapping of what swap pages are in use is one
>> more chunk of data that needs to be assembled and made available through a
>> defined interface.
>>
>>> (4) The user should be able to limit the size of a hibernation image
>>>
>>> There are a couple of reasons of that. For example, the storage space
>>> used for saving the image may be smaller than the entire RAM or the user
>>> may want the image to be saved quickier.
>>
>> it may make sense for this to be split into hard and soft limits.
>>
>> if you try to save more then the storage space can hold you cannot
>> continue, but if you are just a little over the arbatrary size limit that
>> was set to make things fast you are better off saving things as-is then
>> punting, going back to the system, trying to free more ram, and trying a
>> hibernate again.
>>
>> with the kexec approach the enforcment of these limits is also split into
>> two sections.
>>
>> when the hibernate command is given in the main kernel, it's userspace
>> needs to follow some policy to decide how much (if any) memory to free.
>
> How are you going to achieve this without (a) having hibernation-aware
> user space or (b) the freezer?
the hibernate command is a userspace command, but the fact that other
things in userspace are running at the same time is exactly why this is
only an estimate and best-effort as I said in the paragraph below.
>> but since the kexec command and the preporation of the devices can change
>> the memory, the estimates done by the first kernel's userspace are just
>> that, estimates.
>>
>>> (7) On ACPI systems special platform-related actions have to be carried out at
>>> the right points, so that the platform works correctly after the restore
>>>
>>> The ACPI specification requires us to invoke some global ACPI methods
>>> during the hibernation and during the restore. Moreover, the ordering of
>>> code related to these ACPI methods may not be arbitrary (eg. some of
>>> them have to be executed after devices are put into low power states etc.).
>>
>> for a pure hibernate mode, you will be powering off the box after saving
>> the suspend image. why are there any special ACPI modes involved?
>
> Because, for example, on my machine the status of power supply (present
> vs not present) is not updated correctly after the restore if ACPI callbacks
> aren't used during the hibernation. That's just experience and it's in line
> with the ACPI spec.
so if a machine is actually powered off the /dev/suspend process won't
work?
remember that the system may run a different OS between the hibernate and
the resume, makeing any assumptions about what state the hardware is in
when you start the resume is a problem.
David Lang
>> now, for suspend-to-ram you need to be aware of every possible power
>> saving option you have and the cost of each of them, and here the ACPI
>> modes are heavily used.
>>
>> I think this is mixing suspend and hibernate still.
>
> Yes, it is, but that's not we who's mixing. We just need to handle some
> systems built with ACPI in mind.
>
> Greetings,
> Rafael
>
>
>
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-15 22:42 ` david
@ 2007-07-15 23:15 ` Alan Stern
2007-07-15 23:22 ` Rafael J. Wysocki
[not found] ` <200707160122.09840.rjw@sisk.pl>
2 siblings, 0 replies; 110+ messages in thread
From: Alan Stern @ 2007-07-15 23:15 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Sun, 15 Jul 2007 david@lang.hm wrote:
> >> for a pure hibernate mode, you will be powering off the box after saving
> >> the suspend image. why are there any special ACPI modes involved?
> >
> > Because, for example, on my machine the status of power supply (present
> > vs not present) is not updated correctly after the restore if ACPI callbacks
> > aren't used during the hibernation. That's just experience and it's in line
> > with the ACPI spec.
>
> so if a machine is actually powered off the /dev/suspend process won't
> work?
>
> remember that the system may run a different OS between the hibernate and
> the resume, makeing any assumptions about what state the hardware is in
> when you start the resume is a problem.
As I understand it, running a different OS between the hibernate and
the resume would violate the ACPI spec.
Alan Stern
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-15 22:42 ` david
2007-07-15 23:15 ` Alan Stern
@ 2007-07-15 23:22 ` Rafael J. Wysocki
[not found] ` <200707160122.09840.rjw@sisk.pl>
2 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-15 23:22 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Monday, 16 July 2007 00:42, david@lang.hm wrote:
> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
> >> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
> >>
> >>> Hi,
> >>>
> >>> Since many alternative approaches to hibernation are now being considered and
> >>> discussed, I thought it might be a good idea to list some things that in my not
> >>> so humble opinion should be taken care of by any hibernation framework. They
> >>> are listed below, not in any particular order, because I think they all are
> >>> important. Still, I might have forgotten something, so everyone with
> >>> experience in implementing hibernation, especially Pavel and Nigel, please
> >>> check if the list is complete.
> >>>
> >>> (1) Filesystems mounted before the hibernation are untouchable
> >>>
> >>> When there's a memory snapshot, either in the form of a hibernation image,
> >>> or in the form of the "old" kernel and processes available to the "new"
> >>> kexeced kernel responsible for saving their memory, the filesystems mounted
> >>> before the hibernation should not be accessed, even for reading, because
> >>> that would cause their on-disk state to be inconsistent with the snapshot
> >>> and might lead to a filesystem corruption.
> >>
> >> AFAIK this is only the case with ext3, all other filesystems could be
> >> accessed read-only safely
> >>
> >> this is arguably a bug with ext3 (and has been discussed as such), but
> >> right now the ext3 team has decided not to change this bahavior so
> >> hibernate needs to work around it. but don't mistake a work-around for a
> >> single (admittedly very popular) filesystem with a hard and fast
> >> directive.
> >>
> >>> (2) Swap space in use before the hibernation must be handled with care
> >>>
> >>> If swap space is used for saving the memory snapshot, the snapshot-saving
> >>> application (or kernel) must be careful enough not to overwrite swap pages
> >>> that contain valid memory contents stored in there before the hibernation.
> >>
> >> true, in fact, given that many distros and live-CD's autodetect swap
> >> partitions and consider them fair game, I would argue that the best thing
> >> to do would be to have the main system free up it's swap partitions before
> >> going into hibernation.
> >>
> >> however, this could be a decision of the particular hibernate routines.
> >>
> >> for the kexec approach the mapping of what swap pages are in use is one
> >> more chunk of data that needs to be assembled and made available through a
> >> defined interface.
> >>
> >>> (4) The user should be able to limit the size of a hibernation image
> >>>
> >>> There are a couple of reasons of that. For example, the storage space
> >>> used for saving the image may be smaller than the entire RAM or the user
> >>> may want the image to be saved quickier.
> >>
> >> it may make sense for this to be split into hard and soft limits.
> >>
> >> if you try to save more then the storage space can hold you cannot
> >> continue, but if you are just a little over the arbatrary size limit that
> >> was set to make things fast you are better off saving things as-is then
> >> punting, going back to the system, trying to free more ram, and trying a
> >> hibernate again.
> >>
> >> with the kexec approach the enforcment of these limits is also split into
> >> two sections.
> >>
> >> when the hibernate command is given in the main kernel, it's userspace
> >> needs to follow some policy to decide how much (if any) memory to free.
> >
> > How are you going to achieve this without (a) having hibernation-aware
> > user space or (b) the freezer?
>
> the hibernate command is a userspace command, but the fact that other
> things in userspace are running at the same time is exactly why this is
> only an estimate and best-effort as I said in the paragraph below.
>
> >> but since the kexec command and the preporation of the devices can change
> >> the memory, the estimates done by the first kernel's userspace are just
> >> that, estimates.
> >>
> >>> (7) On ACPI systems special platform-related actions have to be carried out at
> >>> the right points, so that the platform works correctly after the restore
> >>>
> >>> The ACPI specification requires us to invoke some global ACPI methods
> >>> during the hibernation and during the restore. Moreover, the ordering of
> >>> code related to these ACPI methods may not be arbitrary (eg. some of
> >>> them have to be executed after devices are put into low power states etc.).
> >>
> >> for a pure hibernate mode, you will be powering off the box after saving
> >> the suspend image. why are there any special ACPI modes involved?
> >
> > Because, for example, on my machine the status of power supply (present
> > vs not present) is not updated correctly after the restore if ACPI callbacks
> > aren't used during the hibernation. That's just experience and it's in line
> > with the ACPI spec.
>
> so if a machine is actually powered off the /dev/suspend process won't
> work?
No, it sort of works as usual, but after the restore the platform is not in the
correct state.
> remember that the system may run a different OS between the hibernate and
> the resume, makeing any assumptions about what state the hardware is in
> when you start the resume is a problem.
True, that's problematic.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <200707160122.09840.rjw@sisk.pl>]
* Re: Hibernation considerations
[not found] ` <200707160122.09840.rjw@sisk.pl>
@ 2007-07-15 23:49 ` david
2007-07-16 12:06 ` Rafael J. Wysocki
0 siblings, 1 reply; 110+ messages in thread
From: david @ 2007-07-15 23:49 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> On Monday, 16 July 2007 00:42, david@lang.hm wrote:
>> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>>
>>> On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
>>>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
>>>>
>>>>> The ACPI specification requires us to invoke some global ACPI methods
>>>>> during the hibernation and during the restore. Moreover, the ordering of
>>>>> code related to these ACPI methods may not be arbitrary (eg. some of
>>>>> them have to be executed after devices are put into low power states etc.).
>>>>
>>>> for a pure hibernate mode, you will be powering off the box after saving
>>>> the suspend image. why are there any special ACPI modes involved?
>>>
>>> Because, for example, on my machine the status of power supply (present
>>> vs not present) is not updated correctly after the restore if ACPI callbacks
>>> aren't used during the hibernation. That's just experience and it's in line
>>> with the ACPI spec.
>>
>> so if a machine is actually powered off the /dev/suspend process won't
>> work?
>
> No, it sort of works as usual, but after the restore the platform is not in the
> correct state.
this is not hibernate as I and many others are thinking of it.
hibernate as we are thinking would work on basicly any hardware, including
things with no ACPI or power savings support. and the system could be in
hibernate mode for any time period.
for that matter, after a system is put into hibernate mode the system
could be completely disassembled and any components replaced and the
system would work after a resume (assuming you still have access to the
suspend image)
>> remember that the system may run a different OS between the hibernate and
>> the resume, makeing any assumptions about what state the hardware is in
>> when you start the resume is a problem.
>
> True, that's problematic.
putting it mildly.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-15 23:49 ` david
@ 2007-07-16 12:06 ` Rafael J. Wysocki
2007-07-16 12:38 ` Jim Crilly
0 siblings, 1 reply; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-16 12:06 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Monday, 16 July 2007 01:49, david@lang.hm wrote:
> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Monday, 16 July 2007 00:42, david@lang.hm wrote:
> >> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> >>
> >>> On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
> >>>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
> >>>>
> >>>>> The ACPI specification requires us to invoke some global ACPI methods
> >>>>> during the hibernation and during the restore. Moreover, the ordering of
> >>>>> code related to these ACPI methods may not be arbitrary (eg. some of
> >>>>> them have to be executed after devices are put into low power states etc.).
> >>>>
> >>>> for a pure hibernate mode, you will be powering off the box after saving
> >>>> the suspend image. why are there any special ACPI modes involved?
> >>>
> >>> Because, for example, on my machine the status of power supply (present
> >>> vs not present) is not updated correctly after the restore if ACPI callbacks
> >>> aren't used during the hibernation. That's just experience and it's in line
> >>> with the ACPI spec.
> >>
> >> so if a machine is actually powered off the /dev/suspend process won't
> >> work?
> >
> > No, it sort of works as usual, but after the restore the platform is not in the
> > correct state.
>
> this is not hibernate as I and many others are thinking of it.
>
> hibernate as we are thinking would work on basicly any hardware, including
> things with no ACPI or power savings support. and the system could be in
> hibernate mode for any time period.
>
> for that matter, after a system is put into hibernate mode the system
> could be completely disassembled and any components replaced and the
> system would work after a resume (assuming you still have access to the
> suspend image)
Well, this is not how ACPI defines the S4 sleep state. If the system is in
S4, that corresponds to our hibernation, you are _not_ allowed to disassemble
it.
I've just done an experiment on my test desktop. I had enabled suspend support
in the CMOS setup and afterwards I made Linux hibernate in the "platform" mode.
Then, when the system was powred on, the BIOS showed me a nice "Resume from
hibernation" screen that is not normally displayed during boot. This clearly
means that some information has been preserved by the platform across the
hibernate/restore cycle. We are supposed to handle that.
Greetngs,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
2007-07-16 12:06 ` Rafael J. Wysocki
@ 2007-07-16 12:38 ` Jim Crilly
2007-07-16 15:29 ` Rafael J. Wysocki
[not found] ` <200707161729.16440.rjw@sisk.pl>
0 siblings, 2 replies; 110+ messages in thread
From: Jim Crilly @ 2007-07-16 12:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On 07/16/07 02:06:27PM +0200, Rafael J. Wysocki wrote:
> On Monday, 16 July 2007 01:49, david@lang.hm wrote:
> > On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> >
> > > On Monday, 16 July 2007 00:42, david@lang.hm wrote:
> > >> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> > >>
> > >>> On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
> > >>>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
> > >>>>
> > >>>>> The ACPI specification requires us to invoke some global ACPI methods
> > >>>>> during the hibernation and during the restore. Moreover, the ordering of
> > >>>>> code related to these ACPI methods may not be arbitrary (eg. some of
> > >>>>> them have to be executed after devices are put into low power states etc.).
> > >>>>
> > >>>> for a pure hibernate mode, you will be powering off the box after saving
> > >>>> the suspend image. why are there any special ACPI modes involved?
> > >>>
> > >>> Because, for example, on my machine the status of power supply (present
> > >>> vs not present) is not updated correctly after the restore if ACPI callbacks
> > >>> aren't used during the hibernation. That's just experience and it's in line
> > >>> with the ACPI spec.
> > >>
> > >> so if a machine is actually powered off the /dev/suspend process won't
> > >> work?
> > >
> > > No, it sort of works as usual, but after the restore the platform is not in the
> > > correct state.
> >
> > this is not hibernate as I and many others are thinking of it.
> >
> > hibernate as we are thinking would work on basicly any hardware, including
> > things with no ACPI or power savings support. and the system could be in
> > hibernate mode for any time period.
> >
> > for that matter, after a system is put into hibernate mode the system
> > could be completely disassembled and any components replaced and the
> > system would work after a resume (assuming you still have access to the
> > suspend image)
>
> Well, this is not how ACPI defines the S4 sleep state. If the system is in
> S4, that corresponds to our hibernation, you are _not_ allowed to disassemble
> it.
>
> I've just done an experiment on my test desktop. I had enabled suspend support
> in the CMOS setup and afterwards I made Linux hibernate in the "platform" mode.
> Then, when the system was powred on, the BIOS showed me a nice "Resume from
> hibernation" screen that is not normally displayed during boot. This clearly
> means that some information has been preserved by the platform across the
> hibernate/restore cycle. We are supposed to handle that.
>
What I believe he's getting at is that Linux hibernation shouldn't be tied
to any ACPI states. Yes, when available and working most people will want
to enter ACPI S4 but we should still have the option of doing a normal
poweroff. With the latter method it would look just like regular power off/on
cycle to the firmware. And that would definitely be useful for things like
working around buggy ACPI implementations or supporting platforms that don't
do ACPI at all. That is the difference between the platform and shutdown
options in /sys/power/disk, isn't it?
> Greetngs,
> Rafael
>
Jim.
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-16 12:38 ` Jim Crilly
@ 2007-07-16 15:29 ` Rafael J. Wysocki
[not found] ` <200707161729.16440.rjw@sisk.pl>
1 sibling, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-16 15:29 UTC (permalink / raw)
To: Jim Crilly
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Monday, 16 July 2007 14:38, Jim Crilly wrote:
> On 07/16/07 02:06:27PM +0200, Rafael J. Wysocki wrote:
> > On Monday, 16 July 2007 01:49, david@lang.hm wrote:
> > > On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> > >
> > > > On Monday, 16 July 2007 00:42, david@lang.hm wrote:
> > > >> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> > > >>
> > > >>> On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
> > > >>>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
> > > >>>>
> > > >>>>> The ACPI specification requires us to invoke some global ACPI methods
> > > >>>>> during the hibernation and during the restore. Moreover, the ordering of
> > > >>>>> code related to these ACPI methods may not be arbitrary (eg. some of
> > > >>>>> them have to be executed after devices are put into low power states etc.).
> > > >>>>
> > > >>>> for a pure hibernate mode, you will be powering off the box after saving
> > > >>>> the suspend image. why are there any special ACPI modes involved?
> > > >>>
> > > >>> Because, for example, on my machine the status of power supply (present
> > > >>> vs not present) is not updated correctly after the restore if ACPI callbacks
> > > >>> aren't used during the hibernation. That's just experience and it's in line
> > > >>> with the ACPI spec.
> > > >>
> > > >> so if a machine is actually powered off the /dev/suspend process won't
> > > >> work?
> > > >
> > > > No, it sort of works as usual, but after the restore the platform is not in the
> > > > correct state.
> > >
> > > this is not hibernate as I and many others are thinking of it.
> > >
> > > hibernate as we are thinking would work on basicly any hardware, including
> > > things with no ACPI or power savings support. and the system could be in
> > > hibernate mode for any time period.
> > >
> > > for that matter, after a system is put into hibernate mode the system
> > > could be completely disassembled and any components replaced and the
> > > system would work after a resume (assuming you still have access to the
> > > suspend image)
> >
> > Well, this is not how ACPI defines the S4 sleep state. If the system is in
> > S4, that corresponds to our hibernation, you are _not_ allowed to disassemble
> > it.
> >
> > I've just done an experiment on my test desktop. I had enabled suspend support
> > in the CMOS setup and afterwards I made Linux hibernate in the "platform" mode.
> > Then, when the system was powred on, the BIOS showed me a nice "Resume from
> > hibernation" screen that is not normally displayed during boot. This clearly
> > means that some information has been preserved by the platform across the
> > hibernate/restore cycle. We are supposed to handle that.
> >
>
> What I believe he's getting at is that Linux hibernation shouldn't be tied
> to any ACPI states. Yes, when available and working most people will want
> to enter ACPI S4 but we should still have the option of doing a normal
> poweroff. With the latter method it would look just like regular power off/on
> cycle to the firmware. And that would definitely be useful for things like
> working around buggy ACPI implementations or supporting platforms that don't
> do ACPI at all. That is the difference between the platform and shutdown
> options in /sys/power/disk, isn't it?
Yes, but this is not my point.
The point is that there are systems that _require_ the ACPI handling to work
correctly after the restore and we need to that _that_ into consideration.
IOW, there are poeple for whom the non-ACPI framework won't work as expected.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <200707161729.16440.rjw@sisk.pl>]
* Re: Hibernation considerations
[not found] ` <200707161729.16440.rjw@sisk.pl>
@ 2007-07-17 4:28 ` david
2007-07-17 10:42 ` Matthew Garrett
[not found] ` <20070717104231.GA32486@srcf.ucam.org>
0 siblings, 2 replies; 110+ messages in thread
From: david @ 2007-07-17 4:28 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jim Crilly, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> On Monday, 16 July 2007 14:38, Jim Crilly wrote:
>> On 07/16/07 02:06:27PM +0200, Rafael J. Wysocki wrote:
>>> On Monday, 16 July 2007 01:49, david@lang.hm wrote:
>>>> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>>>>
>>>>> On Monday, 16 July 2007 00:42, david@lang.hm wrote:
>>>>>> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>>>>>>
>>>>>>> On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
>>>>>>>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
>>>>>>>>
>>>>>>>>> The ACPI specification requires us to invoke some global ACPI methods
>>>>>>>>> during the hibernation and during the restore. Moreover, the ordering of
>>>>>>>>> code related to these ACPI methods may not be arbitrary (eg. some of
>>>>>>>>> them have to be executed after devices are put into low power states etc.).
>>>>>>>>
>>>>>>>> for a pure hibernate mode, you will be powering off the box after saving
>>>>>>>> the suspend image. why are there any special ACPI modes involved?
>>>>>>>
>>>>>>> Because, for example, on my machine the status of power supply (present
>>>>>>> vs not present) is not updated correctly after the restore if ACPI callbacks
>>>>>>> aren't used during the hibernation. That's just experience and it's in line
>>>>>>> with the ACPI spec.
>>>>>>
>>>>>> so if a machine is actually powered off the /dev/suspend process won't
>>>>>> work?
>>>>>
>>>>> No, it sort of works as usual, but after the restore the platform is not in the
>>>>> correct state.
>>>>
>>>> this is not hibernate as I and many others are thinking of it.
>>>>
>>>> hibernate as we are thinking would work on basicly any hardware, including
>>>> things with no ACPI or power savings support. and the system could be in
>>>> hibernate mode for any time period.
>>>>
>>>> for that matter, after a system is put into hibernate mode the system
>>>> could be completely disassembled and any components replaced and the
>>>> system would work after a resume (assuming you still have access to the
>>>> suspend image)
>>>
>>> Well, this is not how ACPI defines the S4 sleep state. If the system is in
>>> S4, that corresponds to our hibernation, you are _not_ allowed to disassemble
>>> it.
>>>
>>> I've just done an experiment on my test desktop. I had enabled suspend support
>>> in the CMOS setup and afterwards I made Linux hibernate in the "platform" mode.
>>> Then, when the system was powred on, the BIOS showed me a nice "Resume from
>>> hibernation" screen that is not normally displayed during boot. This clearly
>>> means that some information has been preserved by the platform across the
>>> hibernate/restore cycle. We are supposed to handle that.
>>>
>>
>> What I believe he's getting at is that Linux hibernation shouldn't be tied
>> to any ACPI states. Yes, when available and working most people will want
>> to enter ACPI S4 but we should still have the option of doing a normal
>> poweroff. With the latter method it would look just like regular power off/on
>> cycle to the firmware. And that would definitely be useful for things like
>> working around buggy ACPI implementations or supporting platforms that don't
>> do ACPI at all. That is the difference between the platform and shutdown
>> options in /sys/power/disk, isn't it?
>
> Yes, but this is not my point.
>
> The point is that there are systems that _require_ the ACPI handling to work
> correctly after the restore and we need to that _that_ into consideration.
>
> IOW, there are poeple for whom the non-ACPI framework won't work as expected.
why would the type of hibernate that I'm talking about (power off, not S4
mode) not work on a box that has ACPI?
you are saying that it wouldn't work right after a restore, but that's
only if the restored image is expecting to have it's devices in ACPI sleep
modes. my answer is "don't do that then" S4 mode does not save power
compared to powering off, and when doing a hibernate you should be
prepared to run out of battery before you wake up, which would then look
like a power-on
the S4 mode sounds like a deeper version of suspend-to-ram, with all of
the limitations of STR becouse you still require power continuously and
must remain in complete control of the machine.
if you want to do a suspend to S4 mode, go for it, but we need to have a
different name for that then for the suspend-to-disk-and-poer-off mode
that I thought was hibernate
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 4:28 ` david
@ 2007-07-17 10:42 ` Matthew Garrett
[not found] ` <20070717104231.GA32486@srcf.ucam.org>
1 sibling, 0 replies; 110+ messages in thread
From: Matthew Garrett @ 2007-07-17 10:42 UTC (permalink / raw)
To: david
Cc: Jim Crilly, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Mon, Jul 16, 2007 at 09:28:13PM -0700, david@lang.hm wrote:
> why would the type of hibernate that I'm talking about (power off, not S4
> mode) not work on a box that has ACPI?
Powering off rather than using S4 means you lose most wakeup device
support. That would be a functional regression compared to the current
code.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <20070717104231.GA32486@srcf.ucam.org>]
* Re: Hibernation considerations
[not found] ` <20070717104231.GA32486@srcf.ucam.org>
@ 2007-07-17 15:19 ` david
[not found] ` <Pine.LNX.4.64.0707170818460.19248@asgard.lang.hm>
1 sibling, 0 replies; 110+ messages in thread
From: david @ 2007-07-17 15:19 UTC (permalink / raw)
To: Matthew Garrett
Cc: Jim Crilly, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Tue, 17 Jul 2007, Matthew Garrett wrote:
> On Mon, Jul 16, 2007 at 09:28:13PM -0700, david@lang.hm wrote:
>
>> why would the type of hibernate that I'm talking about (power off, not S4
>> mode) not work on a box that has ACPI?
>
> Powering off rather than using S4 means you lose most wakeup device
> support. That would be a functional regression compared to the current
> code.
only if the kexec isn't able to initialize those devices.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <Pine.LNX.4.64.0707170818460.19248@asgard.lang.hm>]
* Re: Hibernation considerations
[not found] ` <Pine.LNX.4.64.0707170818460.19248@asgard.lang.hm>
@ 2007-07-18 2:18 ` Matthew Garrett
[not found] ` <20070718021817.GA13502@srcf.ucam.org>
1 sibling, 0 replies; 110+ messages in thread
From: Matthew Garrett @ 2007-07-18 2:18 UTC (permalink / raw)
To: david
Cc: Jim Crilly, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Tue, Jul 17, 2007 at 08:19:32AM -0700, david@lang.hm wrote:
> On Tue, 17 Jul 2007, Matthew Garrett wrote:
> >Powering off rather than using S4 means you lose most wakeup device
> >support. That would be a functional regression compared to the current
> >code.
>
> only if the kexec isn't able to initialize those devices.
If you aren't using ACPI, you probably don't know how to.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <20070718021817.GA13502@srcf.ucam.org>]
* Re: Hibernation considerations
[not found] ` <20070718021817.GA13502@srcf.ucam.org>
@ 2007-07-18 3:54 ` david
2007-07-18 11:10 ` Matthew Garrett
[not found] ` <20070718111016.GA18716@srcf.ucam.org>
0 siblings, 2 replies; 110+ messages in thread
From: david @ 2007-07-18 3:54 UTC (permalink / raw)
To: Matthew Garrett
Cc: Jim Crilly, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Wed, 18 Jul 2007, Matthew Garrett wrote:
> On Tue, Jul 17, 2007 at 08:19:32AM -0700, david@lang.hm wrote:
>> On Tue, 17 Jul 2007, Matthew Garrett wrote:
>>> Powering off rather than using S4 means you lose most wakeup device
>>> support. That would be a functional regression compared to the current
>>> code.
>>
>> only if the kexec isn't able to initialize those devices.
>
> If you aren't using ACPI, you probably don't know how to.
the current kexec patch to allow you to move back to the original kernel
requires ACPI be disabled to work.
that states pretty strongly that kexec isn't dependant on ACPI to
initialize devices.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-18 3:54 ` david
@ 2007-07-18 11:10 ` Matthew Garrett
[not found] ` <20070718111016.GA18716@srcf.ucam.org>
1 sibling, 0 replies; 110+ messages in thread
From: Matthew Garrett @ 2007-07-18 11:10 UTC (permalink / raw)
To: david
Cc: Jim Crilly, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Tue, Jul 17, 2007 at 08:54:24PM -0700, david@lang.hm wrote:
> On Wed, 18 Jul 2007, Matthew Garrett wrote:
>
> >On Tue, Jul 17, 2007 at 08:19:32AM -0700, david@lang.hm wrote:
> >>On Tue, 17 Jul 2007, Matthew Garrett wrote:
> >>>Powering off rather than using S4 means you lose most wakeup device
> >>>support. That would be a functional regression compared to the current
> >>>code.
> >>
> >>only if the kexec isn't able to initialize those devices.
> >
> >If you aren't using ACPI, you probably don't know how to.
>
> the current kexec patch to allow you to move back to the original kernel
> requires ACPI be disabled to work.
Which means it isn't putting the hardware into S4, which means that you
don't get the platform wakeup events.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <20070718111016.GA18716@srcf.ucam.org>]
* Re: Hibernation considerations
[not found] ` <20070718111016.GA18716@srcf.ucam.org>
@ 2007-07-18 12:56 ` david
0 siblings, 0 replies; 110+ messages in thread
From: david @ 2007-07-18 12:56 UTC (permalink / raw)
To: Matthew Garrett
Cc: Jim Crilly, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Wed, 18 Jul 2007, Matthew Garrett wrote:
> On Tue, Jul 17, 2007 at 08:54:24PM -0700, david@lang.hm wrote:
>> On Wed, 18 Jul 2007, Matthew Garrett wrote:
>>
>>> On Tue, Jul 17, 2007 at 08:19:32AM -0700, david@lang.hm wrote:
>>>> On Tue, 17 Jul 2007, Matthew Garrett wrote:
>>>>> Powering off rather than using S4 means you lose most wakeup device
>>>>> support. That would be a functional regression compared to the current
>>>>> code.
>>>>
>>>> only if the kexec isn't able to initialize those devices.
>>>
>>> If you aren't using ACPI, you probably don't know how to.
>>
>> the current kexec patch to allow you to move back to the original kernel
>> requires ACPI be disabled to work.
>
> Which means it isn't putting the hardware into S4, which means that you
> don't get the platform wakeup events.
Ok, I was misunderstanding what you meant by wakeup device support. if you
are meaning things like wake-on-lan then yes, you do loose that with no
ACPI support, but that is acceptable to many people. I understand it's not
for some, and I'm not saying that this should be the only type of suspend,
but I'm also saying that this should be one option.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
2007-07-15 20:13 ` david
[not found] ` <200707160047.28420.rjw@sisk.pl>
@ 2007-07-15 22:47 ` Rafael J. Wysocki
2007-07-15 23:17 ` Alan Stern
2 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-15 22:47 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
>
> > Hi,
> >
> > Since many alternative approaches to hibernation are now being considered and
> > discussed, I thought it might be a good idea to list some things that in my not
> > so humble opinion should be taken care of by any hibernation framework. They
> > are listed below, not in any particular order, because I think they all are
> > important. Still, I might have forgotten something, so everyone with
> > experience in implementing hibernation, especially Pavel and Nigel, please
> > check if the list is complete.
> >
> > (1) Filesystems mounted before the hibernation are untouchable
> >
> > When there's a memory snapshot, either in the form of a hibernation image,
> > or in the form of the "old" kernel and processes available to the "new"
> > kexeced kernel responsible for saving their memory, the filesystems mounted
> > before the hibernation should not be accessed, even for reading, because
> > that would cause their on-disk state to be inconsistent with the snapshot
> > and might lead to a filesystem corruption.
>
> AFAIK this is only the case with ext3, all other filesystems could be
> accessed read-only safely
>
> this is arguably a bug with ext3 (and has been discussed as such), but
> right now the ext3 team has decided not to change this bahavior so
> hibernate needs to work around it. but don't mistake a work-around for a
> single (admittedly very popular) filesystem with a hard and fast
> directive.
>
> > (2) Swap space in use before the hibernation must be handled with care
> >
> > If swap space is used for saving the memory snapshot, the snapshot-saving
> > application (or kernel) must be careful enough not to overwrite swap pages
> > that contain valid memory contents stored in there before the hibernation.
>
> true, in fact, given that many distros and live-CD's autodetect swap
> partitions and consider them fair game, I would argue that the best thing
> to do would be to have the main system free up it's swap partitions before
> going into hibernation.
>
> however, this could be a decision of the particular hibernate routines.
>
> for the kexec approach the mapping of what swap pages are in use is one
> more chunk of data that needs to be assembled and made available through a
> defined interface.
>
> > (4) The user should be able to limit the size of a hibernation image
> >
> > There are a couple of reasons of that. For example, the storage space
> > used for saving the image may be smaller than the entire RAM or the user
> > may want the image to be saved quickier.
>
> it may make sense for this to be split into hard and soft limits.
>
> if you try to save more then the storage space can hold you cannot
> continue, but if you are just a little over the arbatrary size limit that
> was set to make things fast you are better off saving things as-is then
> punting, going back to the system, trying to free more ram, and trying a
> hibernate again.
>
> with the kexec approach the enforcment of these limits is also split into
> two sections.
>
> when the hibernate command is given in the main kernel, it's userspace
> needs to follow some policy to decide how much (if any) memory to free.
How are you going to achieve this without (a) having hibernation-aware
user space or (b) the freezer?
> this could be anything from 'none, try and save all caches' to 'anything
> you can to minimize the amount of data to be saved, trash all caches' to
> something in between like 'try and free up enough memory to get the saved
> data below 1G, but save caches beyond that point'
>
> then when the second kernel runs, it's userspace tools get the list of
> what memory should be saved that the main kernel handed to it, and then
> decides if this is acceptable (probably mostly the hard limits of 'can
> this work') and proceeds to save it somewhere.
>
> but since the kexec command and the preporation of the devices can change
> the memory, the estimates done by the first kernel's userspace are just
> that, estimates.
>
> > (7) On ACPI systems special platform-related actions have to be carried out at
> > the right points, so that the platform works correctly after the restore
> >
> > The ACPI specification requires us to invoke some global ACPI methods
> > during the hibernation and during the restore. Moreover, the ordering of
> > code related to these ACPI methods may not be arbitrary (eg. some of
> > them have to be executed after devices are put into low power states etc.).
>
> for a pure hibernate mode, you will be powering off the box after saving
> the suspend image. why are there any special ACPI modes involved?
Because, for example, on my machine the status of power supply (present
vs not present) is not updated correctly after the restore if ACPI callbacks
aren't used during the hibernation. That's just experience and it's in line
with the ACPI spec.
> now, for suspend-to-ram you need to be aware of every possible power
> saving option you have and the cost of each of them, and here the ACPI
> modes are heavily used.
>
> I think this is mixing suspend and hibernate still.
Yes, it is, but that's not we who's mixing. We just need to handle some
systems built with ACPI in mind.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-15 20:13 ` david
[not found] ` <200707160047.28420.rjw@sisk.pl>
2007-07-15 22:47 ` Rafael J. Wysocki
@ 2007-07-15 23:17 ` Alan Stern
2 siblings, 0 replies; 110+ messages in thread
From: Alan Stern @ 2007-07-15 23:17 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Sun, 15 Jul 2007 david@lang.hm wrote:
> > (1) Filesystems mounted before the hibernation are untouchable
> >
> > When there's a memory snapshot, either in the form of a hibernation image,
> > or in the form of the "old" kernel and processes available to the "new"
> > kexeced kernel responsible for saving their memory, the filesystems mounted
> > before the hibernation should not be accessed, even for reading, because
> > that would cause their on-disk state to be inconsistent with the snapshot
> > and might lead to a filesystem corruption.
>
> AFAIK this is only the case with ext3, all other filesystems could be
> accessed read-only safely
>
> this is arguably a bug with ext3 (and has been discussed as such), but
> right now the ext3 team has decided not to change this bahavior so
> hibernate needs to work around it. but don't mistake a work-around for a
> single (admittedly very popular) filesystem with a hard and fast
> directive.
Isn't is possible to avoid this problem by mounting an ext3 filesystem
as readonly ext2? Provided the filesystem isn't dirty it should be
doable. (And provided the filesystem doesn't use any ext3 extensions
that are incompatible with ext2.)
Alan Stern
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] <200707151433.34625.rjw@sisk.pl>
` (4 preceding siblings ...)
2007-07-15 20:13 ` david
@ 2007-07-15 20:35 ` Cornelius Riemenschneider
[not found] ` <20070715125855.GA1737@gallifrey>
` (2 subsequent siblings)
8 siblings, 0 replies; 110+ messages in thread
From: Cornelius Riemenschneider @ 2007-07-15 20:35 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
Hi,
I think a (10) is needed to be clear:
(10) This depends directly on (9)
Easy Userinterface for the average user, no one wants to edit several
files and use a long commandline for a suspend (not all know about
alias(P)), so keeping the effort to suspend your system low, please.(eg
for my TuxOnIce i just type hibernate as root/ sudo hibernate as normal
user and the suspend begin, the rest is automatically done by the
configuration(for me this is shutting down my wireless interface)
Cornelius Riemenschneider
My source of power: www.humppa.com
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <20070715125855.GA1737@gallifrey>]
[parent not found: <200707160038.12943.rjw@sisk.pl>]
* Re: Hibernation considerations
[not found] ` <200707160038.12943.rjw@sisk.pl>
@ 2007-07-15 22:27 ` david
[not found] ` <Pine.LNX.4.64.0707151526080.25614@asgard.lang.hm>
` (2 subsequent siblings)
3 siblings, 0 replies; 110+ messages in thread
From: david @ 2007-07-15 22:27 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Pavel Machek, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Dr. David Alan Gilbert, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> On Sunday, 15 July 2007 14:58, Dr. David Alan Gilbert wrote:
>> * Rafael J. Wysocki (rjw@sisk.pl) wrote:
>>
>>> (5) Hibernation should be transparent from the applications' point of view
>>>
>>> Generally, applications should not notice that hibernation took place.
>>> [Note that I don't regard all processes as applications and I think that
>>> there may be processes which need to handle the hibernation in a special
>>> way.] Ideally, for example, if some audio is being played when a
>>> hibernation starts, the audio player should be able to continue playing the
>>> same audio after the restore from the point in which it has been
>>> interrupted by the hibernation. Also, the CPU affinities and similar
>>
>> That would be _so_ embarrassing in a library; I'd rather the audio
>> player had the opportunity to consider whether restarting was a good idea.
>>
>>> (6) State of devices from before hibernation should be restored, if possible
>>>
>>> If possible, during a restore devices should be brought back to the same
>>> state in which they were before the corresponding hibernation. Of course
>>> in some situations it might be impossible to do that (eg. the user
>>> connected the hibernated system to a different IP subnet and then
>>> restored), but as a general rule, we should do our best to restore the
>>> state of devices, which is directly related to point (5) above.
>>
>> Or the user unplugs their flash drive after hibernation rather than before.
>>
>> Two things which I think would be nice to consider are:
>> 1) Encryption - I'd actually prefer if my luks device did not
>> remember the key accross a hibernation; I want to be forced to
>> reenter the phrase. However I don't know what the best thing
>> to do to partitions/applications using the luks device is.
>
> Encryption is possible with both the userland hibernation (aka uswsusp) and
> TuxOnIce (formerly known as suspend2). Still, I don't consider it as a "must
> have" feature for a framework to be generally useful (many users don't use it
> anyway).
he's talking about the main system useing an encrypted device/partition,
not the hibernate image being stored encrypted.
This would require the main system 'forget' the keys when it does the
hinbernate and prompt for it again during the wake-up phase.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <Pine.LNX.4.64.0707151526080.25614@asgard.lang.hm>]
* Re: Hibernation considerations
[not found] ` <Pine.LNX.4.64.0707151526080.25614@asgard.lang.hm>
@ 2007-07-17 17:40 ` Dr. David Alan Gilbert
[not found] ` <20070717174044.GA11212@gallifrey>
1 sibling, 0 replies; 110+ messages in thread
From: Dr. David Alan Gilbert @ 2007-07-17 17:40 UTC (permalink / raw)
To: david
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
* david@lang.hm (david@lang.hm) wrote:
> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> >Encryption is possible with both the userland hibernation (aka uswsusp) and
> >TuxOnIce (formerly known as suspend2). Still, I don't consider it as a
> >"must
> >have" feature for a framework to be generally useful (many users don't use
> >it
> >anyway).
>
> he's talking about the main system useing an encrypted device/partition,
> not the hibernate image being stored encrypted.
>
> This would require the main system 'forget' the keys when it does the
> hinbernate and prompt for it again during the wake-up phase.
Indeed - although as I say I really don't know what you would do with
apps using the mounts at that point. Still it seems like a
sensible requrest from the security side.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <20070717174044.GA11212@gallifrey>]
* Re: Hibernation considerations
[not found] ` <20070717174044.GA11212@gallifrey>
@ 2007-07-17 17:49 ` david
0 siblings, 0 replies; 110+ messages in thread
From: david @ 2007-07-17 17:49 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tue, 17 Jul 2007, Dr. David Alan Gilbert wrote:
> * david@lang.hm (david@lang.hm) wrote:
>> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
>
>>> Encryption is possible with both the userland hibernation (aka uswsusp) and
>>> TuxOnIce (formerly known as suspend2). Still, I don't consider it as a
>>> "must
>>> have" feature for a framework to be generally useful (many users don't use
>>> it
>>> anyway).
>>
>> he's talking about the main system useing an encrypted device/partition,
>> not the hibernate image being stored encrypted.
>>
>> This would require the main system 'forget' the keys when it does the
>> hinbernate and prompt for it again during the wake-up phase.
>
> Indeed - although as I say I really don't know what you would do with
> apps using the mounts at that point. Still it seems like a
> sensible requrest from the security side.
along the same lines, it would probably be a good idea to have the ability
for a system to re-ask for the pass phrase periodicly while the system is
running.
I see two possible approaches to these issues.
1. implement the periodic re-request capability, and when going into
hibernate time-out any known pass phrases.
this is a lot of work overall, but the suspend portion is trivial so there
would not be any suspend surprises.
2. flush the keyring on hibernate and have the resume process re-populate
it (either by pokeing directly into the memory, or by providing a table
that the resuming kernel reads from during wake-up to re-populate it)
this is less work, but it's all suspend related so it will get less
testing.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] ` <200707160038.12943.rjw@sisk.pl>
2007-07-15 22:27 ` david
[not found] ` <Pine.LNX.4.64.0707151526080.25614@asgard.lang.hm>
@ 2007-07-29 6:53 ` Vojtech Pavlik
[not found] ` <20070729065352.GB17084@suse.cz>
3 siblings, 0 replies; 110+ messages in thread
From: Vojtech Pavlik @ 2007-07-29 6:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: david, Nigel Cunningham, Pavel Machek, LKML, Kyle Moffett,
Al Boldi, Eric W. Biederman, Dr. David Alan Gilbert, Huang, Ying,
Andrew Morton, pm list, Jeremy Maitin-Shepard
On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
> > Or the user unplugs their flash drive after hibernation rather than before.
> >
> > Two things which I think would be nice to consider are:
> > 1) Encryption - I'd actually prefer if my luks device did not
> > remember the key accross a hibernation; I want to be forced to
> > reenter the phrase. However I don't know what the best thing
> > to do to partitions/applications using the luks device is.
>
> Encryption is possible with both the userland hibernation (aka uswsusp) and
> TuxOnIce (formerly known as suspend2). Still, I don't consider it as a "must
> have" feature for a framework to be generally useful (many users don't use it
> anyway).
If a user uses an encrypted filesystem, then he also needs an encrypted
swap and encrypted hibernation image: Otherwise the fileystem encryption
is not very useful.
Forgetting the filesystem/swap decryption keys before hibernation is
probably harder to do - there may be sensitive data in the kernel memory
image that weren't cleared - even if the key itself is not there.
In my opinion, encrypted hibernation is what every notebook user should
want - that's the only way how to make sure data from the notebook
aren't available when the notebook is physically stolen.
--
Vojtech Pavlik
Director SuSE Labs
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <20070729065352.GB17084@suse.cz>]
* Re: Hibernation considerations
[not found] ` <20070729065352.GB17084@suse.cz>
@ 2007-07-29 9:56 ` Rafael J. Wysocki
0 siblings, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-29 9:56 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: david, Nigel Cunningham, Pavel Machek, LKML, Kyle Moffett,
Al Boldi, Eric W. Biederman, Dr. David Alan Gilbert, Huang, Ying,
Andrew Morton, pm list, Jeremy Maitin-Shepard
On Sunday, 29 July 2007 08:53, Vojtech Pavlik wrote:
> On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
>
> > > Or the user unplugs their flash drive after hibernation rather than before.
> > >
> > > Two things which I think would be nice to consider are:
> > > 1) Encryption - I'd actually prefer if my luks device did not
> > > remember the key accross a hibernation; I want to be forced to
> > > reenter the phrase. However I don't know what the best thing
> > > to do to partitions/applications using the luks device is.
> >
> > Encryption is possible with both the userland hibernation (aka uswsusp) and
> > TuxOnIce (formerly known as suspend2). Still, I don't consider it as a "must
> > have" feature for a framework to be generally useful (many users don't use it
> > anyway).
>
> If a user uses an encrypted filesystem, then he also needs an encrypted
> swap and encrypted hibernation image: Otherwise the fileystem encryption
> is not very useful.
I was talking about hibernation image encryption. Arguably, if the image is
encrypted, you don't need to worry about its contents, including the keys for
other kinds of encryption (eg. fs encryption).
> Forgetting the filesystem/swap decryption keys before hibernation is
> probably harder to do - there may be sensitive data in the kernel memory
> image that weren't cleared - even if the key itself is not there.
If the image is encrypted, its contents are not available to anyone
unauthorized and that includes the filesystem/swap decryption keys.
> In my opinion, encrypted hibernation is what every notebook user should
> want - that's the only way how to make sure data from the notebook
> aren't available when the notebook is physically stolen.
Provided that there are any sensitive (to the user or her employer etc.) data
in the notebook.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] ` <20070715125855.GA1737@gallifrey>
[not found] ` <200707160038.12943.rjw@sisk.pl>
@ 2007-07-15 22:38 ` Rafael J. Wysocki
1 sibling, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-15 22:38 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Sunday, 15 July 2007 14:58, Dr. David Alan Gilbert wrote:
> * Rafael J. Wysocki (rjw@sisk.pl) wrote:
>
> > (5) Hibernation should be transparent from the applications' point of view
> >
> > Generally, applications should not notice that hibernation took place.
> > [Note that I don't regard all processes as applications and I think that
> > there may be processes which need to handle the hibernation in a special
> > way.] Ideally, for example, if some audio is being played when a
> > hibernation starts, the audio player should be able to continue playing the
> > same audio after the restore from the point in which it has been
> > interrupted by the hibernation. Also, the CPU affinities and similar
>
> That would be _so_ embarrassing in a library; I'd rather the audio
> player had the opportunity to consider whether restarting was a good idea.
>
> > (6) State of devices from before hibernation should be restored, if possible
> >
> > If possible, during a restore devices should be brought back to the same
> > state in which they were before the corresponding hibernation. Of course
> > in some situations it might be impossible to do that (eg. the user
> > connected the hibernated system to a different IP subnet and then
> > restored), but as a general rule, we should do our best to restore the
> > state of devices, which is directly related to point (5) above.
>
> Or the user unplugs their flash drive after hibernation rather than before.
>
> Two things which I think would be nice to consider are:
> 1) Encryption - I'd actually prefer if my luks device did not
> remember the key accross a hibernation; I want to be forced to
> reenter the phrase. However I don't know what the best thing
> to do to partitions/applications using the luks device is.
Encryption is possible with both the userland hibernation (aka uswsusp) and
TuxOnIce (formerly known as suspend2). Still, I don't consider it as a "must
have" feature for a framework to be generally useful (many users don't use it
anyway).
> 2) Some level of debugging needs to be available so that users can
> provide something so you can see why something hasn't hibernated
> or why (as in the case of this tosh laptop) it still takes power
> during hibernation.
I agree.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] <200707151433.34625.rjw@sisk.pl>
` (6 preceding siblings ...)
[not found] ` <20070715125855.GA1737@gallifrey>
@ 2007-07-16 0:51 ` Matthew Garrett
[not found] ` <20070716005135.GB8140@srcf.ucam.org>
8 siblings, 0 replies; 110+ messages in thread
From: Matthew Garrett @ 2007-07-16 0:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: david, LKML, Kyle Moffett, Al Boldi, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Sun, Jul 15, 2007 at 02:33:32PM +0200, Rafael J. Wysocki wrote:
(snip)
Many of these assumptions are based on the assumption that we want to
save a full image of RAM. I'm not convinced that this is true. The two
things that we need are application state and hardware state.
Application state can clearly be saved without kernel involvement
(though restoring some of it may need some help from the kernel...), so
hardware state is a more interesting question.
The obvious argument for saving the entirity of memory is that we have
no mechanism for picking apart hardware state from any other part of the
kernel. In reality, we're looking at implementing a set of hibernation
operations anyway - it would be possible to utilise those to save as
much state as needed. You also get fringe benefits, like being able to
freeze a process that's accessing a piece of flaky hardware, swap the
card out (assuming hotplug PCI), restore some amount of state and then
let the process continue.
I appreciate that this suggestion sounds kind of fragile and
complicated, but I think that's true of most descriptions of suspend to
disk :) The main benefit is that it means we can use the hibernation
infrastructure for other purposes (checkpointing, swapping hardware,
that kind of thing) and reduce the damage caused by users doing
seemingly reasonable things (like suspending Linux, booting Windows and
then writing to a shared partition...).
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <20070716005135.GB8140@srcf.ucam.org>]
* Re: Hibernation considerations
[not found] ` <20070716005135.GB8140@srcf.ucam.org>
@ 2007-07-16 0:51 ` david
0 siblings, 0 replies; 110+ messages in thread
From: david @ 2007-07-16 0:51 UTC (permalink / raw)
To: Matthew Garrett
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 02:33:32PM +0200, Rafael J. Wysocki wrote:
>
> (snip)
>
> Many of these assumptions are based on the assumption that we want to
> save a full image of RAM. I'm not convinced that this is true. The two
> things that we need are application state and hardware state.
> Application state can clearly be saved without kernel involvement
> (though restoring some of it may need some help from the kernel...), so
> hardware state is a more interesting question.
one other reason for saving all the ram is that some people want to save
all the system caches so that the machine is just as responsive immediatly
after the resume as it was before the hibernate.
> The obvious argument for saving the entirity of memory is that we have
> no mechanism for picking apart hardware state from any other part of the
> kernel. In reality, we're looking at implementing a set of hibernation
> operations anyway - it would be possible to utilise those to save as
> much state as needed. You also get fringe benefits, like being able to
> freeze a process that's accessing a piece of flaky hardware, swap the
> card out (assuming hotplug PCI), restore some amount of state and then
> let the process continue.
>
> I appreciate that this suggestion sounds kind of fragile and
> complicated, but I think that's true of most descriptions of suspend to
> disk :) The main benefit is that it means we can use the hibernation
> infrastructure for other purposes (checkpointing, swapping hardware,
> that kind of thing) and reduce the damage caused by users doing
> seemingly reasonable things (like suspending Linux, booting Windows and
> then writing to a shared partition...).
I see the order being a little different.
if anyone implements a reliable checkpoint/restore of applications then
that could be used as to pause specific applicaitons, move applications
from one machine to another, move applications from one kernel to another,
and as a side effect, as a form of hibernation when you are willing to
loose your cache in favor of storing as little info as possible (since you
wouldn't need to store the cache memory or any kernel memory/state)
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707151918340.30402-100000@netrider.rowland.org>
@ 2007-07-15 23:58 ` david
2007-07-16 5:02 ` Al Boldi
[not found] ` <200707160802.46567.a1426z@gawab.com>
2 siblings, 0 replies; 110+ messages in thread
From: david @ 2007-07-15 23:58 UTC (permalink / raw)
To: Alan Stern
Cc: Al Boldi, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Sun, 15 Jul 2007, Alan Stern wrote:
> On Sun, 15 Jul 2007, Al Boldi wrote:
>
>> Alan Stern wrote:
>>> On Sun, 15 Jul 2007, Al Boldi wrote:
>
>>>> This should be the responsibility of the kexec'd hibernating kernel.
>>>> Note though in (6), the normal kernel takes care of preparing devices,
>>>> then the hibernating kernel dumps the image and either calls S4 or S3.
>>>> On resume from S3 it can immediately switch over to the normal kernel,
>>>> and from S4 the known bootup would occur.
>>>
>>> Is it really that simple? Somehow I doubt it. In order for some
>>> devices to remain available for the kexec'd kernel to use, they cannot
>>> be suspended at the ACPI level. So the kexec'd kernel will have to
>>> handle the ACPI requirements for those devices. Likewise, it would
>>> have to handle the ACPI interactions which need to be done after all
>>> devices are prepared for the transition to S3 or S4.
>>
>> Ok, after applying the latest kexec patches, I was able to use the kexec'd
>> kernel to suspend to ram and resume to the normal kernel, while working
>> under a full-blown X session. It went without a hitch. All that is needed
>> now are the dump/restore hibernation-image routines.
>
> That's exactly my point. While doing suspend-to-RAM from a kexec'd
> kernel may be simple, saving the hibernation image will add
> complications.
suspend-to-RAM should not involve kexec, the only reason for doing the
kexec to to get a seperate userspace to use for suspend-to-disk operations
instead of trying to partially freeze the sustem and keep useing it.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707151918340.30402-100000@netrider.rowland.org>
2007-07-15 23:58 ` david
@ 2007-07-16 5:02 ` Al Boldi
[not found] ` <200707160802.46567.a1426z@gawab.com>
2 siblings, 0 replies; 110+ messages in thread
From: Al Boldi @ 2007-07-16 5:02 UTC (permalink / raw)
To: Alan Stern
Cc: david, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
Alan Stern wrote:
> As for the VGA font, the effect is easy to see: Run setfont before
> hibernating; when you resume the original font will be back. The
> kernel simply does not bother to save the VGA font information across a
> hibernate.
This could probably be handled by a device suspend/resume call; but this
problem is not specific to kexec.
> > Ok, after applying the latest kexec patches, I was able to use the
> > kexec'd kernel to suspend to ram and resume to the normal kernel, while
> > working under a full-blown X session. It went without a hitch. All
> > that is needed now are the dump/restore hibernation-image routines.
>
> That's exactly my point. While doing suspend-to-RAM from a kexec'd
> kernel may be simple, saving the hibernation image will add
> complications.
>From a kexec'd hibernation kernel pov, both S3 and S4 look conceptually
exactly the same. The only difference is, in S3 the memory is in memory and
in S4 the memory is on storage. All device handling is exactly the same, so
if there is a problem with device handling between the kexec'd hibernation
kernel and the normal kernel, then that would have made itself visible.
david@lang.hm wrote:
> suspend-to-RAM should not involve kexec, the only reason for doing the
> kexec to to get a seperate userspace to use for suspend-to-disk operations
> instead of trying to partially freeze the sustem and keep useing it.
Or you could do suspend-to-disk-and-RAM. But in the above case, it was meant
to test kexec compatibility with device suspend/resume calls.
Thanks!
--
Al
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <200707160802.46567.a1426z@gawab.com>]
* Re: Hibernation considerations
[not found] ` <200707160802.46567.a1426z@gawab.com>
@ 2007-07-16 6:49 ` david
2007-07-16 13:32 ` Al Boldi
[not found] ` <200707161632.02334.a1426z@gawab.com>
2007-07-16 14:53 ` Alan Stern
1 sibling, 2 replies; 110+ messages in thread
From: david @ 2007-07-16 6:49 UTC (permalink / raw)
To: Al Boldi
Cc: linux-kernel, Kyle Moffett, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Al Boldi wrote:
>
> david@lang.hm wrote:
>> suspend-to-RAM should not involve kexec, the only reason for doing the
>> kexec to to get a seperate userspace to use for suspend-to-disk operations
>> instead of trying to partially freeze the sustem and keep useing it.
>
> Or you could do suspend-to-disk-and-RAM. But in the above case, it was meant
> to test kexec compatibility with device suspend/resume calls.
the point I am trying to make here is that there is no reason that the
kexec approach needs to do _any_ suspend/resume calls.
all that is needed is the ability of the new kernel to initialize the
devices it needs.
suspend-to-disk-and-ram could be implemented as three
seperate steps
1. suspend-to-disk
2. resume-from-disk
3. suspend-to-ram
followed by either
4. resume-from-ram
or
4. battery dies and loptop powers off completely
5. power-on boot.
6. resume-from-disk
all that you need to do is to make sure that the system doesn't run
anything that would affect permanent media or the outside world between
steps #2 and #3
yes it's more steps, but each step is logicly seperate, and each step will
be excercised on a regular basis, so the combination of the steps will
also be reliable.
this is far better then creating yet another way to pause the system that
only a few people will use.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-16 6:49 ` david
@ 2007-07-16 13:32 ` Al Boldi
[not found] ` <200707161632.02334.a1426z@gawab.com>
1 sibling, 0 replies; 110+ messages in thread
From: Al Boldi @ 2007-07-16 13:32 UTC (permalink / raw)
To: david
Cc: linux-kernel, Kyle Moffett, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
david@lang.hm wrote:
> On Mon, 16 Jul 2007, Al Boldi wrote:
> > david@lang.hm wrote:
> >> suspend-to-RAM should not involve kexec, the only reason for doing the
> >> kexec to to get a seperate userspace to use for suspend-to-disk
> >> operations instead of trying to partially freeze the sustem and keep
> >> useing it.
> >
> > Or you could do suspend-to-disk-and-RAM. But in the above case, it was
> > meant to test kexec compatibility with device suspend/resume calls.
>
> the point I am trying to make here is that there is no reason that the
> kexec approach needs to do _any_ suspend/resume calls.
When you go through ACPI, then that implies calling suspend/resume calls.
> all that is needed is the ability of the new kernel to initialize the
> devices it needs.
We have to go through ACPI, for wakeup functions to succeed. A simple
power-off won't do.
> suspend-to-disk-and-ram could be implemented as three
> seperate steps
>
> 1. suspend-to-disk
>
> 2. resume-from-disk
>
> 3. suspend-to-ram
>
> followed by either
>
> 4. resume-from-ram
>
> or
>
> 4. battery dies and loptop powers off completely
>
> 5. power-on boot.
>
> 6. resume-from-disk
>
> all that you need to do is to make sure that the system doesn't run
> anything that would affect permanent media or the outside world between
> steps #2 and #3
Exactly, which is why your scheme would break down on #3, and that's why you
need to call S3 from within the kexec'd hibernation kernel after saving the
hibernation image.
Thanks!
--
Al
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <200707161632.02334.a1426z@gawab.com>]
* Re: Hibernation considerations
[not found] ` <200707161632.02334.a1426z@gawab.com>
@ 2007-07-17 4:33 ` david
2007-07-17 12:08 ` Al Boldi
[not found] ` <200707171508.06921.a1426z@gawab.com>
0 siblings, 2 replies; 110+ messages in thread
From: david @ 2007-07-17 4:33 UTC (permalink / raw)
To: Al Boldi
Cc: linux-kernel, Kyle Moffett, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Al Boldi wrote:
> david@lang.hm wrote:
>> On Mon, 16 Jul 2007, Al Boldi wrote:
>>> david@lang.hm wrote:
>>>> suspend-to-RAM should not involve kexec, the only reason for doing the
>>>> kexec to to get a seperate userspace to use for suspend-to-disk
>>>> operations instead of trying to partially freeze the sustem and keep
>>>> useing it.
>>>
>>> Or you could do suspend-to-disk-and-RAM. But in the above case, it was
>>> meant to test kexec compatibility with device suspend/resume calls.
>>
>> the point I am trying to make here is that there is no reason that the
>> kexec approach needs to do _any_ suspend/resume calls.
>
> When you go through ACPI, then that implies calling suspend/resume calls.
then don't go through ACPI
>> all that is needed is the ability of the new kernel to initialize the
>> devices it needs.
>
> We have to go through ACPI, for wakeup functions to succeed. A simple
> power-off won't do.
the kexec switch being posted requires ACPI be disabled, so it's clearly
possible to switch kernels and initialize devices without ACPI
>> suspend-to-disk-and-ram could be implemented as three
>> seperate steps
>>
>> 1. suspend-to-disk
>>
>> 2. resume-from-disk
>>
>> 3. suspend-to-ram
>>
>> followed by either
>>
>> 4. resume-from-ram
>>
>> or
>>
>> 4. battery dies and loptop powers off completely
>>
>> 5. power-on boot.
>>
>> 6. resume-from-disk
>>
>> all that you need to do is to make sure that the system doesn't run
>> anything that would affect permanent media or the outside world between
>> steps #2 and #3
>
> Exactly, which is why your scheme would break down on #3, and that's why you
> need to call S3 from within the kexec'd hibernation kernel after saving the
> hibernation image.
when a kexec is called, how does the kernel know what to execute?
something needs to tell it what to do, and I think that something is
either something in the kexec image, or it's something passed as a
parameter to that image.
all that would be needed to do #3 safely is to have the kernel that you
restarted on #2 do a suspend-to-ram before it does anything else.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
2007-07-17 4:33 ` david
@ 2007-07-17 12:08 ` Al Boldi
[not found] ` <200707171508.06921.a1426z@gawab.com>
1 sibling, 0 replies; 110+ messages in thread
From: Al Boldi @ 2007-07-17 12:08 UTC (permalink / raw)
To: david
Cc: linux-kernel, Kyle Moffett, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
david@lang.hm wrote:
> On Mon, 16 Jul 2007, Al Boldi wrote:
> > We have to go through ACPI, for wakeup functions to succeed. A simple
> > power-off won't do.
>
> the kexec switch being posted requires ACPI be disabled, so it's clearly
> possible to switch kernels and initialize devices without ACPI
It's a given that kexec works in the absence of ACPI; what we have to handle
is the ACPI states across kernel invocations, to ensure wakeup functions
succeed. If you don't need this, then just power off.
> >> suspend-to-disk-and-ram could be implemented as three
> >> seperate steps
> >>
> >> 1. suspend-to-disk
> >>
> >> 2. resume-from-disk
> >>
> >> 3. suspend-to-ram
> >>
> >> followed by either
> >>
> >> 4. resume-from-ram
> >>
> >> or
> >>
> >> 4. battery dies and loptop powers off completely
> >>
> >> 5. power-on boot.
> >>
> >> 6. resume-from-disk
> >>
> >> all that you need to do is to make sure that the system doesn't run
> >> anything that would affect permanent media or the outside world between
> >> steps #2 and #3
> >
> > Exactly, which is why your scheme would break down on #3, and that's why
> > you need to call S3 from within the kexec'd hibernation kernel after
> > saving the hibernation image.
>
> when a kexec is called, how does the kernel know what to execute?
> something needs to tell it what to do, and I think that something is
> either something in the kexec image, or it's something passed as a
> parameter to that image.
>
> all that would be needed to do #3 safely is to have the kernel that you
> restarted on #2 do a suspend-to-ram before it does anything else.
If you mean by kernel 'the normal kernel', then this won't work, because it
would imply a change of state after saving its image.
If you mean by kernel 'the kexec'd hibernation kernel', then you wouldn't
need to do #2, but rather do #3 right after dumping the image in #1.
[...insert from another post...]
> > BTW, it would be really helpful if people would actually try the kexec
> > hibernation patches, as this may yield a much more constructive
> > discussion.
>
> I would love to, but so far I don't see the nessasary pieces
>
> once I kexec to the new kernel, how can it find out what pages of memory
> (and swap) need to be saved?
No need to save the swap, all you need to do is to dump /dev/oldmem onto
storage, and if that dump image is compatible with swsusp, then a normal
kernel should be able to resume from this image via /dev/snapshot.
Thanks!
--
Al
^ permalink raw reply [flat|nested] 110+ messages in thread[parent not found: <200707171508.06921.a1426z@gawab.com>]
* Re: Hibernation considerations
[not found] ` <200707171508.06921.a1426z@gawab.com>
@ 2007-07-17 14:18 ` Rafael J. Wysocki
2007-07-17 15:23 ` david
1 sibling, 0 replies; 110+ messages in thread
From: Rafael J. Wysocki @ 2007-07-17 14:18 UTC (permalink / raw)
To: Al Boldi
Cc: david, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Tuesday, 17 July 2007 14:08, Al Boldi wrote:
> david@lang.hm wrote:
> > On Mon, 16 Jul 2007, Al Boldi wrote:
> > > We have to go through ACPI, for wakeup functions to succeed. A simple
> > > power-off won't do.
> >
> > the kexec switch being posted requires ACPI be disabled, so it's clearly
> > possible to switch kernels and initialize devices without ACPI
>
> It's a given that kexec works in the absence of ACPI; what we have to handle
> is the ACPI states across kernel invocations, to ensure wakeup functions
> succeed. If you don't need this, then just power off.
>
> > >> suspend-to-disk-and-ram could be implemented as three
> > >> seperate steps
> > >>
> > >> 1. suspend-to-disk
> > >>
> > >> 2. resume-from-disk
> > >>
> > >> 3. suspend-to-ram
> > >>
> > >> followed by either
> > >>
> > >> 4. resume-from-ram
> > >>
> > >> or
> > >>
> > >> 4. battery dies and loptop powers off completely
> > >>
> > >> 5. power-on boot.
> > >>
> > >> 6. resume-from-disk
> > >>
> > >> all that you need to do is to make sure that the system doesn't run
> > >> anything that would affect permanent media or the outside world between
> > >> steps #2 and #3
> > >
> > > Exactly, which is why your scheme would break down on #3, and that's why
> > > you need to call S3 from within the kexec'd hibernation kernel after
> > > saving the hibernation image.
> >
> > when a kexec is called, how does the kernel know what to execute?
> > something needs to tell it what to do, and I think that something is
> > either something in the kexec image, or it's something passed as a
> > parameter to that image.
> >
> > all that would be needed to do #3 safely is to have the kernel that you
> > restarted on #2 do a suspend-to-ram before it does anything else.
>
> If you mean by kernel 'the normal kernel', then this won't work, because it
> would imply a change of state after saving its image.
>
> If you mean by kernel 'the kexec'd hibernation kernel', then you wouldn't
> need to do #2, but rather do #3 right after dumping the image in #1.
>
> [...insert from another post...]
> > > BTW, it would be really helpful if people would actually try the kexec
> > > hibernation patches, as this may yield a much more constructive
> > > discussion.
> >
> > I would love to, but so far I don't see the nessasary pieces
> >
> > once I kexec to the new kernel, how can it find out what pages of memory
> > (and swap) need to be saved?
>
> No need to save the swap,
Correct.
> all you need to do is to dump /dev/oldmem onto storage,
I'm not sure of that.
> and if that dump image is compatible with swsusp,
No, it's not. swusp additionally needs to know PFNs to restore the pages into.
> then a normal kernel should be able to resume from this image via
> /dev/snapshot.
Nope.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
[not found] ` <200707171508.06921.a1426z@gawab.com>
2007-07-17 14:18 ` Rafael J. Wysocki
@ 2007-07-17 15:23 ` david
1 sibling, 0 replies; 110+ messages in thread
From: david @ 2007-07-17 15:23 UTC (permalink / raw)
To: Al Boldi
Cc: linux-kernel, Kyle Moffett, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Tue, 17 Jul 2007, Al Boldi wrote:
> david@lang.hm wrote:
>> On Mon, 16 Jul 2007, Al Boldi wrote:
>>> We have to go through ACPI, for wakeup functions to succeed. A simple
>>> power-off won't do.
>>
>> the kexec switch being posted requires ACPI be disabled, so it's clearly
>> possible to switch kernels and initialize devices without ACPI
>
> It's a given that kexec works in the absence of ACPI; what we have to handle
> is the ACPI states across kernel invocations, to ensure wakeup functions
> succeed. If you don't need this, then just power off.
>
>>>> suspend-to-disk-and-ram could be implemented as three
>>>> seperate steps
>>>>
>>>> 1. suspend-to-disk
>>>>
>>>> 2. resume-from-disk
>>>>
>>>> 3. suspend-to-ram
>>>>
>>>> followed by either
>>>>
>>>> 4. resume-from-ram
>>>>
>>>> or
>>>>
>>>> 4. battery dies and loptop powers off completely
>>>>
>>>> 5. power-on boot.
>>>>
>>>> 6. resume-from-disk
>>>>
>>>> all that you need to do is to make sure that the system doesn't run
>>>> anything that would affect permanent media or the outside world between
>>>> steps #2 and #3
>>>
>>> Exactly, which is why your scheme would break down on #3, and that's why
>>> you need to call S3 from within the kexec'd hibernation kernel after
>>> saving the hibernation image.
>>
>> when a kexec is called, how does the kernel know what to execute?
>> something needs to tell it what to do, and I think that something is
>> either something in the kexec image, or it's something passed as a
>> parameter to that image.
>>
>> all that would be needed to do #3 safely is to have the kernel that you
>> restarted on #2 do a suspend-to-ram before it does anything else.
>
> If you mean by kernel 'the normal kernel', then this won't work, because it
> would imply a change of state after saving its image.
yes, it would change the state, but if it only changes the state in ways
that aren't visable to the outside world why would it matter?
if power dies you restore from the disk image (useing the non ACPI
approach), and the changes that you make are just lost
> If you mean by kernel 'the kexec'd hibernation kernel', then you wouldn't
> need to do #2, but rather do #3 right after dumping the image in #1.
>
> [...insert from another post...]
>>> BTW, it would be really helpful if people would actually try the kexec
>>> hibernation patches, as this may yield a much more constructive
>>> discussion.
>>
>> I would love to, but so far I don't see the nessasary pieces
>>
>> once I kexec to the new kernel, how can it find out what pages of memory
>> (and swap) need to be saved?
>
> No need to save the swap, all you need to do is to dump /dev/oldmem onto
> storage, and if that dump image is compatible with swsusp, then a normal
> kernel should be able to resume from this image via /dev/snapshot.
Rafael is saying that there's more involved, you can't just dump
/dev/oldmem, you have to avoid specific pages.
as for swap, saving that may be required, depending on how clean you want
toleave the box for other OS's in the meantime.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] ` <200707160802.46567.a1426z@gawab.com>
2007-07-16 6:49 ` david
@ 2007-07-16 14:53 ` Alan Stern
1 sibling, 0 replies; 110+ messages in thread
From: Alan Stern @ 2007-07-16 14:53 UTC (permalink / raw)
To: Al Boldi
Cc: david, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Mon, 16 Jul 2007, Al Boldi wrote:
> From a kexec'd hibernation kernel pov, both S3 and S4 look conceptually
> exactly the same. The only difference is, in S3 the memory is in memory and
> in S4 the memory is on storage. All device handling is exactly the same, so
> if there is a problem with device handling between the kexec'd hibernation
> kernel and the normal kernel, then that would have made itself visible.
You have contradicted yourself. "In S3 the memory is in memory and in
S4 the memory is on storage". How does the memory get onto storage?
The kexec'd hibernation kernel writes it there. To do so it accesses a
storage device.
Consequently the device handling _cannot_ be exactly the same in S3 and
S4.
Alan Stern
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707151914450.28934-100000@netrider.rowland.org>
@ 2007-07-15 23:38 ` Nigel Cunningham
2007-07-15 23:41 ` david
1 sibling, 0 replies; 110+ messages in thread
From: Nigel Cunningham @ 2007-07-15 23:38 UTC (permalink / raw)
To: Alan Stern
Cc: david, Al Boldi, LKML, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
[-- Attachment #1.1: Type: text/plain, Size: 1267 bytes --]
Hi.
On Monday 16 July 2007 09:15:47 Alan Stern wrote:
> On Sun, 15 Jul 2007 david@lang.hm wrote:
>
> > >> for a pure hibernate mode, you will be powering off the box after
saving
> > >> the suspend image. why are there any special ACPI modes involved?
> > >
> > > Because, for example, on my machine the status of power supply (present
> > > vs not present) is not updated correctly after the restore if ACPI
callbacks
> > > aren't used during the hibernation. That's just experience and it's in
line
> > > with the ACPI spec.
> >
> > so if a machine is actually powered off the /dev/suspend process won't
> > work?
> >
> > remember that the system may run a different OS between the hibernate and
> > the resume, makeing any assumptions about what state the hardware is in
> > when you start the resume is a problem.
>
> As I understand it, running a different OS between the hibernate and
> the resume would violate the ACPI spec.
Well then, I know one or two people who would argue that the ACPI spec is
faulty. :\
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707151914450.28934-100000@netrider.rowland.org>
2007-07-15 23:38 ` Nigel Cunningham
@ 2007-07-15 23:41 ` david
1 sibling, 0 replies; 110+ messages in thread
From: david @ 2007-07-15 23:41 UTC (permalink / raw)
To: Alan Stern
Cc: LKML, Kyle Moffett, Al Boldi, Eric W. Biederman, Pavel Machek,
Huang, Ying, Andrew Morton, pm list, Jeremy Maitin-Shepard
On Sun, 15 Jul 2007, Alan Stern wrote:
> On Sun, 15 Jul 2007 david@lang.hm wrote:
>
>>>> for a pure hibernate mode, you will be powering off the box after saving
>>>> the suspend image. why are there any special ACPI modes involved?
>>>
>>> Because, for example, on my machine the status of power supply (present
>>> vs not present) is not updated correctly after the restore if ACPI callbacks
>>> aren't used during the hibernation. That's just experience and it's in line
>>> with the ACPI spec.
>>
>> so if a machine is actually powered off the /dev/suspend process won't
>> work?
>>
>> remember that the system may run a different OS between the hibernate and
>> the resume, makeing any assumptions about what state the hardware is in
>> when you start the resume is a problem.
>
> As I understand it, running a different OS between the hibernate and
> the resume would violate the ACPI spec.
then we need a third mode of operation.
mode 1: Suspend-to-ram
the system is paused and put into a low-power mode but data remains in
memory and the system stays awake enough to keep the memory refreshed.
mode 2: new
the system is paused, data is stored to permanent media, and the system
is put into a ultra-low power mode.
mode 3: hibernate
the system is paused, data is stored to permanent media, and the system
is powered off
with mode 3 there are no requirements or limitations about what can be
done with the hardware before a resume (the resume could even take place
on a different piece of identical hardware)
mode 2 could be what you are talking about doing, although I don't see any
advantage of creating it in additon to mode 3, it doesn't use any less
power and it locks the system so that it can't be used for anything else
in the meantime. I guess if it was significantly faster to do then mode 3
there may be _some_ reason to consider it, but I don't see the speed
difference.
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707151220570.24011-100000@netrider.rowland.org>
@ 2007-07-15 17:40 ` Al Boldi
2007-07-15 19:52 ` david
1 sibling, 0 replies; 110+ messages in thread
From: Al Boldi @ 2007-07-15 17:40 UTC (permalink / raw)
To: Alan Stern
Cc: david, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
Alan Stern wrote:
> On Sun, 15 Jul 2007, Al Boldi wrote:
> > > If possible, during a restore devices should be brought back to
> > > the same state in which they were before the corresponding
> > > hibernation. Of course in some situations it might be impossible to
> > > do that (eg. the user connected the hibernated system to a different
> > > IP subnet and then restored), but as a general rule, we should do our
> > > best to restore the state of devices, which is directly related to
> > > point (5) above.
> >
> > This part could easily be handled by the normal kernel before and after
> > resume.
>
> I agree with you except for the word "easily". And there are some
> things the kernel simply punts on (I'm thinking of the current VGA
> font).
Why; can you explain?
> > > (7) On ACPI systems special platform-related actions have to be
> > > carried out at the right points, so that the platform works correctly
> > > after the restore
> > >
> > > The ACPI specification requires us to invoke some global ACPI
> > > methods during the hibernation and during the restore. Moreover, the
> > > ordering of code related to these ACPI methods may not be arbitrary
> > > (eg. some of them have to be executed after devices are put into low
> > > power states etc.).
> >
> > This should be the responsibility of the kexec'd hibernating kernel.
> > Note though in (6), the normal kernel takes care of preparing devices,
> > then the hibernating kernel dumps the image and either calls S4 or S3.
> > On resume from S3 it can immediately switch over to the normal kernel,
> > and from S4 the known bootup would occur.
>
> Is it really that simple? Somehow I doubt it. In order for some
> devices to remain available for the kexec'd kernel to use, they cannot
> be suspended at the ACPI level. So the kexec'd kernel will have to
> handle the ACPI requirements for those devices. Likewise, it would
> have to handle the ACPI interactions which need to be done after all
> devices are prepared for the transition to S3 or S4.
Ok, after applying the latest kexec patches, I was able to use the kexec'd
kernel to suspend to ram and resume to the normal kernel, while working
under a full-blown X session. It went without a hitch. All that is needed
now are the dump/restore hibernation-image routines.
> > > (8) Hibernation and restore should not be too slow
> > >
> > > In my opinion, if more than one minute is needed to hibernate the
> > > system with the help of certain hibernation framework, then this
> > > framework is not very useful in practice. It might be useful to
> > > perform some special tasks (eg. moving a server to another place
> > > without taking it down), but it is not very useful, for example, to
> > > notebook users.
> >
> > The latest hibernating kexec patches boot a kexec'd modular kernel with
> > initramfs into crashkernel=16M@16M in less than one second. Switch-back
> > is almost instant. Add to this the time required to either store or
> > restore the image, and it may be obvious that this approach isn't
> > slower, but maybe even faster than the current swsusp.
>
> Does that include the time required for probing PCI buses? On my
> desktop system, PCI probing incurs a five-second timeout delay because
> of a bug in the BIOS's USB firmware.
Using a modular kernel you would only insmod those modules that you need to
dump the image, which is mainly the diskdriver. If you wanted to dump it
onto USB flash, then you would insmod that driver, and if that driver is
slow due to a bug, then a fix should be in order.
> Don't be so sure that kexec will
> always be lightning fast; it is always better to avoid unnecessary
> boots.
Agreed, but what we want to achieve right know is a proof of concept. Later,
I could imagine a specially stub'd device driver to be kexec'd instead of
the full kernel.
Thanks!
--
Al
^ permalink raw reply [flat|nested] 110+ messages in thread* Re: Hibernation considerations
[not found] <Pine.LNX.4.44L0.0707151220570.24011-100000@netrider.rowland.org>
2007-07-15 17:40 ` Al Boldi
@ 2007-07-15 19:52 ` david
1 sibling, 0 replies; 110+ messages in thread
From: david @ 2007-07-15 19:52 UTC (permalink / raw)
To: Alan Stern
Cc: Al Boldi, linux-kernel, Kyle Moffett, Eric W. Biederman,
Pavel Machek, Huang, Ying, Andrew Morton, pm list,
Jeremy Maitin-Shepard
On Sun, 15 Jul 2007, Alan Stern wrote:
>>> (7) On ACPI systems special platform-related actions have to be carried
>>> out at the right points, so that the platform works correctly after the
>>> restore
>>>
>>> The ACPI specification requires us to invoke some global ACPI methods
>>> during the hibernation and during the restore. Moreover, the ordering
>>> of code related to these ACPI methods may not be arbitrary (eg. some of
>>> them have to be executed after devices are put into low power states
>>> etc.).
>>
>> This should be the responsibility of the kexec'd hibernating kernel. Note
>> though in (6), the normal kernel takes care of preparing devices, then the
>> hibernating kernel dumps the image and either calls S4 or S3. On resume
>> from S3 it can immediately switch over to the normal kernel, and from S4 the
>> known bootup would occur.
>
> Is it really that simple? Somehow I doubt it. In order for some
> devices to remain available for the kexec'd kernel to use, they cannot
> be suspended at the ACPI level. So the kexec'd kernel will have to
> handle the ACPI requirements for those devices. Likewise, it would
> have to handle the ACPI interactions which need to be done after all
> devices are prepared for the transition to S3 or S4.
so if there are two states for hardware
1. able to be detected and initialized with the standard boot routines
2. ACPI suspend mode, requireing ACPI specifics to wake up
is it possible to detect which is needed? cna you try the ACPI wakeup and
if it doesn't work go to the standard boot routine (or vice-versa)?
>>> (8) Hibernation and restore should not be too slow
>>>
>>> In my opinion, if more than one minute is needed to hibernate the
>>> system with the help of certain hibernation framework, then this framework
>>> is not very useful in practice. It might be useful to perform some
>>> special tasks (eg. moving a server to another place without taking it
>>> down), but it is not very useful, for example, to notebook users.
>>
>> The latest hibernating kexec patches boot a kexec'd modular kernel with
>> initramfs into crashkernel=16M@16M in less than one second. Switch-back is
>> almost instant. Add to this the time required to either store or restore
>> the image, and it may be obvious that this approach isn't slower, but maybe
>> even faster than the current swsusp.
>
> Does that include the time required for probing PCI buses? On my
> desktop system, PCI probing incurs a five-second timeout delay because
> of a bug in the BIOS's USB firmware. Don't be so sure that kexec will
> always be lightning fast; it is always better to avoid unnecessary
> boots.
some drivers will have delays on some machines (especially when you
consider hardware bugs that have to be worked around), but at the moment
nothing is remotely close to the 'limit' of 60 seconds being talked about
here.
although with some machines the mear trasnfer times for the data could
cause noticable delays (if you have a server with 128G of ram it may take
a while to get it to a drive)
David Lang
^ permalink raw reply [flat|nested] 110+ messages in thread