IBM/MontaVista Dynamic Power Management Project

IBM/MontaVista Dynamic Power Management Project

[Bishop Brock]

IBM and MontaVista have initiated a joint project to develop a
dynamic power management control and policy mechanism for Linux
for processors supporting dynamic voltage and frequency scaling.
A paper describing the proposal can be obtained from

http://www.research.ibm.com/arl/projects/dpm.html

A working prototype of the proposed framework for
the IBM PowerPC 405LP processor exists and will be made
public in the near future.

Bishop Brock

IBM Research, Austin Center for Low-Power Computing
11400 Burnet Road    MS/904-6F021
Austin, TX 78758
(512) 838-0149    IBM T/L 678-0149

Re: IBM/MontaVista Dynamic Power Management Project

[Arjan van de Ven]

On Tue, 2002-12-03 at 18:46, Bishop Brock wrote:
> IBM and MontaVista have initiated a joint project to develop a
> dynamic power management control and policy mechanism for Linux
> for processors supporting dynamic voltage and frequency scaling.
> A paper describing the proposal can be obtained from
> 
> http://www.research.ibm.com/arl/projects/dpm.html
> 
> A working prototype of the proposed framework for
> the IBM PowerPC 405LP processor exists and will be made
> public in the near future.

any idea if/how this will fit into the existing cross platform cpufreq
framework ?

Re: [Linux-pm-devel] Re: IBM/MontaVista Dynamic Power Management Project

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Tue, 2002-12-03 at 11:57, Arjan van de Ven wrote:
> On Tue, 2002-12-03 at 18:46, Bishop Brock wrote:
> > IBM and MontaVista have initiated a joint project to develop a
> > dynamic power management control and policy mechanism for Linux
> > for processors supporting dynamic voltage and frequency scaling.
> > A paper describing the proposal can be obtained from
> > 
> > http://www.research.ibm.com/arl/projects/dpm.html
> > 
> > A working prototype of the proposed framework for
> > the IBM PowerPC 405LP processor exists and will be made
> > public in the near future.
> 
> any idea if/how this will fit into the existing cross platform cpufreq
> framework ?

It subsumes it, similar to Dominik's ideas in "[RFC] Dynamic Frequency
and Voltage Scaling Infrastructure" (on the cpufreq list). The idea is
that you want scaling events to be generated by the kernel rather than
only scaling on userland input. The paper (and Dominik's mail) give you
some ideas of when and why...

-Hollis
-- 
PowerPC Linux
IBM Linux Technology Center

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-pm-devel] Re: IBM/MontaVista Dynamic Power Management Project

[Dominik Brodowski]

On Tue, Dec 03, 2002 at 12:27:03PM -0600, Hollis Blanchard wrote:
> On Tue, 2002-12-03 at 11:57, Arjan van de Ven wrote:
> > On Tue, 2002-12-03 at 18:46, Bishop Brock wrote:
> > > IBM and MontaVista have initiated a joint project to develop a
> > > dynamic power management control and policy mechanism for Linux
> > > for processors supporting dynamic voltage and frequency scaling.

Great!

> > > A paper describing the proposal can be obtained from
> > > 
> > > http://www.research.ibm.com/arl/projects/dpm.html
> > > 
> > > A working prototype of the proposed framework for
> > > the IBM PowerPC 405LP processor exists and will be made
> > > public in the near future.
> > 
> > any idea if/how this will fit into the existing cross platform cpufreq
> > framework ?
> 
> It subsumes it, similar to Dominik's ideas in "[RFC] Dynamic Frequency
> and Voltage Scaling Infrastructure" (on the cpufreq list). The idea is
> that you want scaling events to be generated by the kernel rather than
> only scaling on userland input. The paper (and Dominik's mail) give you
> some ideas of when and why...

So, will it basically be a "policy governor" as described in my "[RFC]" mail?
Or does it need other enhancements in the cpufreq core? 

BTW, have you noticed the premilinary patch I which implements most of the 
DVS infrastructure mentioned in my mail to the cpufreq list yesterday?

	Dominik

Re: [Linux-pm-devel] Re: IBM/MontaVista Dynamic Power Management Project

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On Tue, 2002-12-03 at 14:00, Dominik Brodowski wrote:
> On Tue, Dec 03, 2002 at 12:27:03PM -0600, Hollis Blanchard wrote:
> > On Tue, 2002-12-03 at 11:57, Arjan van de Ven wrote:
> > > 
> > > any idea if/how this will fit into the existing cross platform cpufreq
> > > framework ?
> > 
> > It subsumes it, similar to Dominik's ideas in "[RFC] Dynamic Frequency
> > and Voltage Scaling Infrastructure" (on the cpufreq list). The idea is
> > that you want scaling events to be generated by the kernel rather than
> > only scaling on userland input. The paper (and Dominik's mail) give you
> > some ideas of when and why...
> 
> So, will it basically be a "policy governor" as described in my "[RFC]" mail?
> Or does it need other enhancements in the cpufreq core? 
> 
> BTW, have you noticed the premilinary patch I which implements most of the 
> DVS infrastructure mentioned in my mail to the cpufreq list yesterday?

Honestly I haven't had time to read it over and compare and contrast
with the IBM paper. From the sound of things though, I suspect both your
patch and the IBM code implement the same thing: an infrastructure
allowing "governors" to control dynamic scaling. The 405LP code also
includes such a governor of course. The ideas may be almost identical;
I'm not sure anyone's compared at this point. Do you have the time? ;)

-Hollis
-- 
PowerPC Linux
IBM Linux Technology Center

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-pm-devel] Re: IBM/MontaVista Dynamic Power Management Project

[Dominik Brodowski]

On Tue, Dec 03, 2002 at 06:57:49PM +0100, Arjan van de Ven wrote:
> On Tue, 2002-12-03 at 18:46, Bishop Brock wrote:
> > IBM and MontaVista have initiated a joint project to develop a
> > dynamic power management control and policy mechanism for Linux
> > for processors supporting dynamic voltage and frequency scaling.
> > A paper describing the proposal can be obtained from
> > 
> > http://www.research.ibm.com/arl/projects/dpm.html
> > 
> > A working prototype of the proposed framework for
> > the IBM PowerPC 405LP processor exists and will be made
> > public in the near future.
> 
> any idea if/how this will fit into the existing cross platform cpufreq
> framework ?

Actually, if I understand IBM's proposal right, it seems to be an
alternative to cpufreq: a different "mid-layer" between the low-level
processor drivers, other kernel code, and the user. So it's not an extension
to an existing feature, but a new feature - Halloween was some weeks ago...

	Dominik

Re: IBM/MontaVista Dynamic Power Management Project

[Alan Cox]

On Tue, 2002-12-03 at 17:46, Bishop Brock wrote:
> IBM and MontaVista have initiated a joint project to develop a
> dynamic power management control and policy mechanism for Linux
> for processors supporting dynamic voltage and frequency scaling.
> A paper describing the proposal can be obtained from
> 
> http://www.research.ibm.com/arl/projects/dpm.html

Interesting. One small question however. The paper says "Others have
also explored the possibilities of this type of fine grained control".
More to the point however they have patents covering them. What does IBM
intend to do about that ?

Re: [Linux-pm-devel] IBM/MontaVista Dynamic Power Management Project

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

Please note that the cpufreq list address was incorrect in the original
mail; please cc cpufreq@www.linux.org.uk (not .uk.org :) on future
replies.

-Hollis
-- 
PowerPC Linux
IBM Linux Technology Center

On Tue, 2002-12-03 at 11:46, Bishop Brock wrote:
> IBM and MontaVista have initiated a joint project to develop a
> dynamic power management control and policy mechanism for Linux
> for processors supporting dynamic voltage and frequency scaling.
> A paper describing the proposal can be obtained from
> 
> http://www.research.ibm.com/arl/projects/dpm.html
> 
> A working prototype of the proposed framework for
> the IBM PowerPC 405LP processor exists and will be made
> public in the near future.
> 
> Bishop Brock
> 
> IBM Research, Austin Center for Low-Power Computing
> 11400 Burnet Road    MS/904-6F021
> Austin, TX 78758
> (512) 838-0149    IBM T/L 678-0149
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET 
> comprehensive development tool, built to increase your 
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Linux-pm-devel mailing list
> Linux-pm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-pm-devel
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-pm-devel] Re: IBM/MontaVista Dynamic Power Management Project

[Bishop Brock]

Dominik Brodowski <linux@brodo.de> on 12/03/2002 02:00:19 PM
> > > A paper describing the proposal can be obtained from
> > >
> > > http://www.research.ibm.com/arl/projects/dpm.html
> > >

>So, will it basically be a "policy governor" as described in my "[RFC]"
mail?
>Or does it need other enhancements in the cpufreq core?

>BTW, have you noticed the premilinary patch I which implements most of the
>DVS infrastructure mentioned in my mail to the cpufreq list yesterday?

Dominik,

I've read the RFC and am familiar with the DVFS implementation for ARM,
but I have not been following CPUFREQ development closely. Given that
background, I'll try to be brief on describing the two proposals as I
understand them.

Our proposal (DPM) begins from the idea of an abstract, platform-specific
"operating point", and a platform-specific driver(s) that knows how to
move the system to that operating point.  I see CPUFREQ as that driver
for the platforms it supports.  For our embedded systems the sets of
operating points will be fixed by the system designer, but DPM
would allow operating points that were partially interpreted (e.g., the
lowest frequency greater than X), which seems to be used in CPUFREQ.
The enhancement I think for CPUFREQ would be to deal with operating
points, and not explicit voltages and frequencies.  In next-generation
platforms there will be multiple voltages and frequencies in a single
CPU, so we need to abstract this away now.

Many of the things your RFC described as "events", we describe as
"operating states", e.g., idle, running tasks, handling interrupts.
A DPM "policy" maps system operating states to operating points.  Every
time the kernel changes state, the current active policy defines the
operating point the system should run in.  These aspects of the two
proposals are very similar. As you point out, locking (and blocking)
are problems when operating points are changing rapidly, and we've
discussed this problem in our paper (see "Abstract Implementation").

My understanding of your RFC is that what you call "models" we would
call "policies", and that CPUFREQ models are executable. In contrast,
DPM policies are data structures that are maintained in the kernel.
Policies are managed by user- or kernel-level tasks using a "set_policy()"
interface. There's no restriction on what computation is used to decide
which policy to activate, but once activated its action is automatic.

DPM also includes provisions for task-specific operating points, but
we could discuss this further once the legal questions are resolved.

Finally, DPM includes an idea that may not exist in CPUFREQ, and
that is the idea that peripheral devices advertise constraints,
e.g., bus bandwidth requirements (through the Linux Device Model),
and these constraints are used to select the best operating point
that satisfies all of the constraints.  We believe this will be
important for aggressively power-managed embedded CPUs with many
on-board peripherals.  This feature falls out easily where it
is not required, however.

Bishop

Re: [Linux-pm-devel] Re: IBM/MontaVista Dynamic Power Management Project

[Dominik Brodowski]

Hi Bishop,

On Tue, Dec 03, 2002 at 09:34:58PM -0600, Bishop Brock wrote:
> >So, will it basically be a "policy governor" as described in my "[RFC]"
> mail?
> >Or does it need other enhancements in the cpufreq core?
> 
> >BTW, have you noticed the premilinary patch I which implements most of the
> >DVS infrastructure mentioned in my mail to the cpufreq list yesterday?
> 
> Dominik,
> 
> I've read the RFC and am familiar with the DVFS implementation for ARM,
> but I have not been following CPUFREQ development closely.

Actually, CPUFREQ evolved from ARM DVFS.

> Our proposal (DPM) begins from the idea of an abstract, platform-specific
> "operating point", and a platform-specific driver(s) that knows how to
> move the system to that operating point.  I see CPUFREQ as that driver
> for the platforms it supports. 

CPUfreq is about providing a cross-arch interface between other kernel code,
user-space and processor drivers for static and/or dynamic frequency and
voltage scaling. The DPM proposal seems to try to be another such
"mid-layer". And while it might be possible to emulate CPUFREQ as a driver
for DPM, it will be possible in the same way to emulate DPM as a driver for
CPUFREQ. 

> For our embedded systems the sets of
> operating points will be fixed by the system designer, but DPM
> would allow operating points that were partially interpreted (e.g., the
> lowest frequency greater than X), which seems to be used in CPUFREQ.

There already was the discussion about fixed operating points and all sorts
of frequencies back in August, IIRC. If a processor driver only allows fixed
operating points, fine. But limiting the mid-layer to a few fixed operating
points seems very limiting to me. 

> The enhancement I think for CPUFREQ would be to deal with operating
> points, and not explicit voltages and frequencies.  In next-generation
> platforms there will be multiple voltages and frequencies in a single
> CPU, so we need to abstract this away now.

Multiple voltages and frequencies are already supported by current CPUfreq
drivers, e.g. longhaul.c. And I see operating points as a limitation, not as
an enhancement.
 
> Many of the things your RFC described as "events", we describe as
> "operating states", e.g., idle, running tasks, handling interrupts.
> A DPM "policy" maps system operating states to operating points.  Every
> time the kernel changes state, the current active policy defines the
> operating point the system should run in.  These aspects of the two
> proposals are very similar. As you point out, locking (and blocking)
> are problems when operating points are changing rapidly, and we've
> discussed this problem in our paper (see "Abstract Implementation").

Indeed. Duplication of code.

> My understanding of your RFC is that what you call "models" we would
> call "policies", and that CPUFREQ models are executable. In contrast,
> DPM policies are data structures that are maintained in the kernel.
> Policies are managed by user- or kernel-level tasks using a "set_policy()"
> interface. There's no restriction on what computation is used to decide
> which policy to activate, but once activated its action is automatic.

Which means that if DPM was a CPUFREQ policy model / policy governor it
could use these "data structures", offer the set-policy() call -- but
different policy governors (like a real-time DVS model) could also be used.

> DPM also includes provisions for task-specific operating points, but
> we could discuss this further once the legal questions are resolved.

Which could also be "sent through" the CPUFREQ layer to DPM as a policy
governor.

> Finally, DPM includes an idea that may not exist in CPUFREQ, and
> that is the idea that peripheral devices advertise constraints,

Been there, done that. 
cpufreq_register_notifier(*notifier, CPUFREQ_POLICY_NOTIFIER)


While Dynamic Frequency and Voltage Scaling is an important addition to the
Linux kernel, and your proposal offers many fine ideas, I see the following
limitations:

- it offers another "mid-layer" with similar functionality to the current
	cpufreq core.
- because of its incompatibility with cpufreq it seems to be a new feature
	to me. The feature freeze has been some weeks ago. So your proposal
	might only be able to be included in kernel 2.7
- it limits processor drivers to a few operating points instead of offering
	the full functionality to the user, who could then decide which
	"operating points" he uses.
- it only offers one scaling model instead of providing an interface to 
	use different models for different needs like real-time computing


So, instead of you developing a replacement to current cpufreq, I'd suggest 
doing the following:

a) cpufreq driver for IBM PowerPC 405LP
---------------------------------------
Add a cpufreq processor driver for the IBM PowerPC you use as test-bed for
your model. Non-CPU hardware limitations can be taken care of by cpufreq
policy notifiers.

b) DPM as cpufreq governor
--------------------------
The cpufreq governor interface, which is an abstraction of the current
"policy", "powersave" and "24freq" models, will be submitted for inclusion
for Linux 2.5. soon. Based on this governor interface, your DPM proposal
could offer a new feature without interfering with existing kernel code,
but by being just another "driver" for an existing feature.

If there are constraints to the current cpufreq governor model, these
implementation details can easily be talked about. For example, the locking
needs to be improved for DVS, and you might want to add a
"target_processing_bandwith" value.

This way DPM would be much more flexible - it assures that it isn't too closely
based on IBM PowerPC but is indeed cross-arch; it uses existing kernel code
(or code which will hopefully be merged soon) and it avoids code duplication.

So, I'd suggest that we work together in integrating your DPM proposal into
the existing cpufreq framework. As I said before, if any changes to the
cpufreq core are neccessary, these can easily be done as long as they don't 
reduce functionality or break existing features.

	Dominik