On Fri, Aug 06, 2010 at 06:33:25PM +0100, Mark Brown wrote:On Fri, Aug 06, 2010 at 10:22:26AM -0700, Paul E. McKenney wrote:On Fri, Aug 06, 2010 at 01:30:48PM +0100, Mark Brown wrote:
this (the one following the rename to suspend blockers). Essentially
what happens in a mainline context is that some subsystems can with
varying degress of optionality ignore some or all of the instruction to
suspend and keep bits of the system alive during suspend.
This underscores a basic difference between servers and these embedded
devices. When you suspend a server, it is doing nothing, because servers
rely very heavily on the CPUs. In contrast, many embedded devices can
perform useful work even when the CPUs are completely powered down.
Well, not really from the Linux point of view. It's not massively
different to something like keeping an ethernet controller sufficiently
alive to allow it to provide wake on LAN functionality while the system
is suspended in terms of what Linux has to do, and quite a few servers
have lights out management systems which aren't a million miles away
from the modem on a phone in terms of their relationship with the host
computer.
The wake-on-LAN and the lights-out management systems are indeed
interesting examples, and actually pretty good ones. The reason I
excluded them is that they don't do any application processing -- their
only purpose is the care and feeding of the system itself. In contrast,
the embedded processors are able to do significant applications processing
(e.g., play back music) while any CPUs are completely shut down and most
of the memory is powered down as well.