Thread (1 message) 1 message, 1 author, 2007-07-12

Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

flat view

From: Rafael J. Wysocki <hidden>
Date: 2007-07-12 19:38:44
Also in: lkml

On Thursday, 12 July 2007 21:14, david@lang.hm wrote:
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
quoted
quoted
quoted
quoted
note that what devices get put to sleep could be configurable, potentially
to the extreme of things like the OLPC (that have hardware designed for
cheap sleeping) going into a light suspend-to-ram state between keystrokes
if nothing else has a timer event scheduled before that.

Suspend-do-disk (Hibernate) involves stopping the system, makeing a
snapshot of ram, writing the snapshot to somewhere and powering off the
box. on wakeup (power-on) a helper kernel boots, loads the snapshot into
ram and jumps to the kernel in the snapshot to resume operation.

as I understand the proposal the thought is to do the following

1. system kernel does suspend-to-ram to put the devices into a known safe
state.
Not necessarily suspend-to-RAM.  I'd much prefer it if devices were not put
into low power states but quiesced (ie. no DMA, no interrupts).
as I asked in another message, is it really worth having two (or more)
modes here?
I think so.  The suspend-to-RAM mode is quite specific and on some platform
(ie. ACPI) it requires platform support.

We've already reached the conclusion that it's better to separate suspend from
hibernation, as far as device drivers are concerned, and let's not repeat the
discussion.
Ok, I seem to have been miscommunicating here. the old combined 
suspend/hibernate took everything to the hibernate state even if you only 
needed to suspend.
No, quite the other way around.

For creating a hibernation image you don't have to suspend devices.
Furthermore, you don't want to suspend at least some of them, because you'll
be using them to save the image in a while.  Also, there's no need to worry
about what power state to put the device into, so that it can wake up the
system from the sleep state etc.

We've made hibernation use suspend-specific callbacks and that causes quite
a lot of problems to appear.
I was still seeing two diffent states involved

for suspend go to low-power mode

for hibernate go to low-power mode,
No, that is not the way to go, IMO.  We can shut down devices before creating
the image, but not suspend them.
kexec the new kernel, do your stuff, power off 
Here, instead of just powering off, we may want to make the system enter a
sleep state (S4 in ACPI systems), which is similar to suspend.
note that this doesn't really matter as you have pointed out in other 
messages that we don't really want to put things in low-power mode, and 
Eric pointed out that kexec already handles disabling devices, so it 
sounds like this may be a solved problem if he's right and an issue to be 
solved differently if he's not.
Shutting down devices and reinitializing them is costly.  I wouldn't like to
do that.

Of course, in a proof-of-concept version this is viable, but IMO not in the
final one.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help