Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
From: Pavel Machek
Date: Wed Apr 25 2007 - 03:24:29 EST
> This is why there's a lot to be said for
> echo mem > /sys/power/state
> and being able to follow the path through _one_ object (the kernel) over
> trying to figure out the interaction between many different parts with
> different versions.
The 'promise' is 'if you can get echo disk > /sys/power/state working,
uswsusp will work. too'. IOW it should be ok to debug the in-kernel
Even I am running in-kernel swsusp, but my managers were pretty clear
they want graphical progress bar hiding all the 'ugly' swsusp
messages... and in the end the same uswsusp enables compression, too.
> I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
> whole thing. I think they've _all_ caused problems for the "true" suspend
> (suspend-to-ram), and the last thing I want to see is three or four
Well, it is a bit more complex than that.
suspend-to-disk is a workaround for
'suspend-to-ram eats too much power' (plus some details like
being able to replace battery).
suspend-to-ram is a workaround for
'idle machine takes way too much power' (plus some details
like don't spin the disk so that machine is safe to carry).
I'm starting to think that we should fix the idle power consumption
problem. Cell phones do it right. They pretend to be ready/idle all
the time, yet they have _days_ of standby.
OLPC can do something like that, too: it is capable of entering
suspend-to-ram with screen on and input devices ready to wake the
And with right network card (and right userland) ... I think normal
PCs could enter suspend-to-ram during screensaver, too. When you are
about to turn off the screen, machine should enable WOL on any packet,
arm RTC wakeup for the next packet, and s2ram happily.
(Obviously we are far away from that on PC.)
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/