Date:	Thu, 12 Jul 2007 21:45:55 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	david@...g.hm
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Huang, Ying" <ying.huang@...el.com>, Pavel Machek <pavel@....cz>,
	nigel@...el.suspend2.net, Jeremy Maitin-Shepard <jbms@....edu>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

On Thursday, 12 July 2007 21:14, david@...g.hm wrote:
> On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
> 
> >>>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists