On Thursday, 12 July 2007 21:14, [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
