Re: [PATCH 05/13] PM: Add option to disable /sys/power/state interface

Matthew Garrett
2009-02-12T11:16:01Z

On Sun, Feb 08, 2009 at 06:04:04AM -0800, Brian Swetland wrote:

> Being in suspend, where periodic user and kernel timers aren't running,
> and random userspace threads aren't possibly spinning, rather than just
> being in idle in the lowest power possible state, represent a pretty
> significant power savings.

Nokia have produced a Linux-based device that runs off a phone battery
and has roughly a week of standby time without entering an explicit
suspend state at any time, so dealing with this is clearly possible.
What we need is to ensure that driver interfaces allow the kernel to
know when a given piece of hardware is required and place it in an
appropriate power state - the USB autosuspend code is probably the best
kernelwide example of this right now.

Part of the reason you're getting pushback is that your solution to the
problem of shutting down unused hardware is tied to embedded-style
systems with very low resume latencies. You can afford to handle the
problem by entering an explicit suspend state. In the x86 mobile world,
we don't have that option. It's simply too slow and disruptive to the
user experience. As a consequence we're far more interested in hardware
power management that doesn't require an explicit system-wide suspend.

A solution that's focused on powering down as much unused hardware as
possible regardless of the system state benefits the x86 world as well
as the embedded world, so I think there's a fairly strong argument that
it's a better solution than one requiring an explicit system state
change. Arve mentioned that your hardware enters the same power state in
idle as in suspend, so the only real difference here is that in the
"better" solution you're inferring that the hardware is idle based on
the demands of userspace rather than explicitly shutting it down.

At least, from the kernel side. The userspace side is more awkward - as
Pavel suggested you could obtain a pretty similar outcome by just
sending SIGSTOP to pretty much everything, which is kind of ugly but
would probably work.

--
Matthew Garrett | mjg59@srcf.ucam.org