[linux-pm] [RFD] Automatic suspend

[Rafael J. Wysocki]

On Monday 16 February 2009, Arjan van de Ven wrote:
> On Mon, 16 Feb 2009 16:36:43 -0600
> "Woodruff, Richard" <r-woodruff2 at ti.com> wrote:
> 
> > 
> > > From: Arjan van de Ven [mailto:arjan at infradead.org]
> > > Sent: Monday, February 16, 2009 3:52 PM
> > > On Mon, 16 Feb 2009 15:32:06 -0600
> > > "Woodruff, Richard" <r-woodruff2 at ti.com> wrote:
> > > >
> > > > - It provides a way to handle overdrive/turbo operating points
> > > > out of band from the generically tuned cpufreq governors like
> > > > ondemand.  The way we characterize overdrive is stricter then
> > > > what Intel has talked about for x86.
> > >
> > > if you have an improved-for-your-systems governor then I'm sure
> > > that is very welcome in the kernel.
> > 
> > No, the generic governors were not substantially improved. Not every
> > customer is using cpufreq for DVFS. As such we went underneath it. If
> > we had more community presence at the start time we might have also
> > tried that.
> > 
> > > I think just about all of us agree that the final decision needs to
> > > be in the driver (possibly followed by something that gets various
> > > device requests and combines it into hw settings); we're just
> > > talking about what inputs feed into that decision ;)
> > >
> > > And for different types of devices that's guaranteed to be
> > > different... and sometimes we'll be hampered by existing
> > > interfaces, so we might end up with hacky stuff.
> > 
> > Is there some kind of roadmap which can be plotted which goes from
> > course to more granular control?
> > 
> > Phase 1 (all or nothing): like wakelocks (minus back light):
> > system-auto-suspend-on, system-auto-suspend-off.  The drivers can
> > still veto as they do today.
> > 
> > Phase 2: Subsystem generic tunable, on say latency + bandwidth. Start
> > with CPU then move to classes like USB.
> 
> I think your phases are the wrong way around.
> Phase 2 is already in progress and many of the "good" drivers and
> subsystems already do them.
> 
> 
> Whole system suspend is a much more drastic thing; I don't see that
> happen generically in 2009 to be honest (not to mention how fragile
> linux suspend is).

This applies to x86/ACPI mostly, IMO.  Embedded platforms appear to be much
more controllable and tend to work better w/ system-wide sleep states.

> In addition, in hardware there does seem to be the trend where idle and
> suspend are converging (just look at the OLPC)...   with chipsets powering
> down all unused pieces, and cpus in idle taking basically no power, there
> no longer is much of a difference in reality between suspend and good-idle...

This, again, seems to be a bit x86-centric. :-)  The Android people are telling
us that on the hardware they deal with it does make sense to put the entire
system to sleep even for relatively short periods of time, since the latencies
involved are not too bad.

While I agree that on a PC it would probably make more sense to go towards
fine-grained run-time power management, maybe even without using system-wide
suspend at all (I don't see this happen any time soon, though), I'm not sure
about the other platforms.

Thanks,
Rafael