OLS 2006 PM-BOF notes

OLS 2006 PM-BOF notes

[Mark Gross]

OLS 2006 PM BOF notes

I'm sorry for taking so long to get these out, I misplaced my notes such as
there are.  The discussions where fragmented and hard to keep up with.  

The following is what I've managed to recall from my chicken scratches.  Feel
free to correct and amend these notes or discuss the items.

--mgross

CPUFREQ :
Too many governors.  Can we collapse some of the governors that have a lot of
code in common?  Should the conservative governor be implemented as a
constraint to the on demand driver / implemented by passing tuning parameters?

Can we remove the power save and performance governors?

Profiling applications:

Influence is coming from the embedded folks.  About 33% or more of BOF the
attendees where representing the embedded Linux users.

Application hints to OS PM behaviors needed.

How to make dynamic policy changes? (e.g. "shut down cpus on 36-way box on low
demand times")

Device / driver Policy manager for application based PM:

Can drivers be put into lower power states based on application hints, such as
I'm doing DVD play back and don't need HD, Ethernet, USB, BT so shut those down
for now.

Need drivers to support going to low power states:
Building the driver knowledge of clock dependencies?
Nokia's clock/voltage frame work for OMAP

Predicable suspend and resume times:

Re: OLS 2006 PM-BOF notes

[Dave Jones]

On Thu, Aug 10, 2006 at 02:18:18PM -0700, Mark Gross wrote:
 
 > CPUFREQ :
 > Too many governors.  Can we collapse some of the governors that have a lot of
 > code in common?  Should the conservative governor be implemented as a
 > constraint to the on demand driver / implemented by passing tuning parameters?

This has been proposed a few times. Just needs someone to do the work.

 > Can we remove the power save and performance governors?

Personally, I have no objection, as I never use them, but you can guarantee
someone will concoct a use-case for them.

		Dave

-- 
http://www.codemonkey.org.uk

Re: OLS 2006 PM-BOF notes

[Scott E. Preece]

| From: Mark Gross<mgross@linux.intel.com>
| 
| OLS 2006 PM BOF notes
| 
| I'm sorry for taking so long to get these out, I misplaced my notes such as
| there are.  The discussions where fragmented and hard to keep up with.  
| ...
| Device / driver Policy manager for application based PM:
| 
| Can drivers be put into lower power states based on application hints, such as
| I'm doing DVD play back and don't need HD, Ethernet, USB, BT so shut those down
| for now.
---

Problem, of course, is that in general-use kind of environment, one
application doesn't know what another is doing. So, an app could say "I
need X, Y, Z" or "I don't need X, Y, Z", but something needs to track
the requirements across the system as a whole. And, then, you either
have to trust the applications (which seems unworkable, as long as the
software set can be changed on a deployed system) or else you have to
have a backup approach that controls things by watching the system. And,
if you have that, do you really need the app hints, too?

Now, a narrow consumer device with non-replaceable software might be
able to get away with just voluntary controls, but (a) the FLOSS
community is getting sensitive about whether non-replaceable software is
permissible and (b) a lot of consumer devices are skewing more towards
general use, anyway, so being able to count on cooperative apps is
probably unrealistic.

Look at the narrow case of CPU demand; most apps (other than simple
filter-style apps) have multiple execution regimes while they're
running - the DVD player doesn't need a lit of CPU while it's waiting for
you to press PLAY. So coders would have to remember to change hints as
they changed modes, which seems like a stretch. And you need a means of
expressing your hints in a way that doesn't depend on knowledge of the
platform, or else the developer needs to test on every supported
platform and calculate requirements for that hardware.

The MontaVista/IBM white paper on DPM talked about seeing gains just
from stopping during the inter-frame breaks in video decoding. If you've
got dynamic ticks, and the app is tied to a timer to restart its
activity for the next frame, you can probably do as well by just letting
the scheduler drive that as by asking the app to carefully indicate when
it's not going to need processing.

scott

-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

Re: OLS 2006 PM-BOF notes

[Mark Gross]

On Fri, Aug 11, 2006 at 02:14:19PM -0500, Scott E. Preece wrote:
> 
> 
> | From: Mark Gross<mgross@linux.intel.com>
> | 
> | OLS 2006 PM BOF notes
> | 
> | I'm sorry for taking so long to get these out, I misplaced my notes such as
> | there are.  The discussions where fragmented and hard to keep up with.  
> | ...
> | Device / driver Policy manager for application based PM:
> | 
> | Can drivers be put into lower power states based on application hints, such as
> | I'm doing DVD play back and don't need HD, Ethernet, USB, BT so shut those down
> | for now.
> ---
> 
> Problem, of course, is that in general-use kind of environment, one
> application doesn't know what another is doing. So, an app could say "I
> need X, Y, Z" or "I don't need X, Y, Z", but something needs to track
> the requirements across the system as a whole. And, then, you either
> have to trust the applications (which seems unworkable, as long as the
> software set can be changed on a deployed system) or else you have to
> have a backup approach that controls things by watching the system. And,
> if you have that, do you really need the app hints, too?

point

> 
> Now, a narrow consumer device with non-replaceable software might be
> able to get away with just voluntary controls, but (a) the FLOSS
> community is getting sensitive about whether non-replaceable software is
> permissible and (b) a lot of consumer devices are skewing more towards
> general use, anyway, so being able to count on cooperative apps is
> probably unrealistic.
> 
> Look at the narrow case of CPU demand; most apps (other than simple
> filter-style apps) have multiple execution regimes while they're
> running - the DVD player doesn't need a lit of CPU while it's waiting for
> you to press PLAY. So coders would have to remember to change hints as
> they changed modes, which seems like a stretch. And you need a means of
> expressing your hints in a way that doesn't depend on knowledge of the
> platform, or else the developer needs to test on every supported
> platform and calculate requirements for that hardware.

Now that we have dynaticks coming with HRT in the next few kernels we
have part of the problme solved.  The next step is to enable better
resource need predition at the system level based on both responivenes
and throughput needs to round out the PM story.

If we could know that we need Xmsec responce in UI events, and we have
Ysec of playback buffer in the audio hardware, and we have similar data
from key IO devices that know about latencies and throughput collected
somewhere that a policy manager could do a good job of knowing what
lower power states can be attempted and by what devices, that would help
a lot.

> 
> The MontaVista/IBM white paper on DPM talked about seeing gains just
> from stopping during the inter-frame breaks in video decoding. If you've
> got dynamic ticks, and the app is tied to a timer to restart its
> activity for the next frame, you can probably do as well by just letting
> the scheduler drive that as by asking the app to carefully indicate when
> it's not going to need processing.

What is needed is a way for media applications to set a deadline based
on how large the playback buffer is, fill it, yeald and then if the
system is otherwise idle, drop into a deep C state (x86) or high latency
sleep (ARM) as a function of how much time is left before the buffer is
drained out.

For this to work you need the system to know how long before it needs to
ramp back up and schedule it to do so.

It would be good to consider how this type of latency and CPU wake up
from deep idle scheduling could look in Linux.

--mgross