Re: [Dynamicpower-devel] DPM model

[Todd P. <tod...@gm...>]

On Wednesday 25 April 2007 05:31:35 Manish RATHI wrote:
> Is there any plan to merge them in main stream kernel?

There have been attempts to discuss the whole of DPM and to split out
a piece of it for consideration on its own.  Although the IBM research
lab that spawned DPM is no longer involved, I imagine at least
MontaVista (and maybe WindRiver) and possibly some embedded chipset
vendors continue to hope for improvements in Linux support for
embedded platforms along the lines of what DPM offers.  I've gotten
away from it myself as of late, so I'm not sure of the most recent
status.  Many of the previous objections had to do with the relatively
complicated interfaces needed in the kernel to create PM information
with multiple subfields, and to select policies by name instead of
single-integer-valued CPU speeds, and so forth (meanwhile, support for
the ACPI monstrosity continues unabated).  There is also cpufreq,
which is based on very different interfaces, but can be made to handle
many similar situations.

The DPM notion of a system "operating point" comprised of a number of
power/performance-related hardware register values (or other more
abstract values that cause hardware changes) met with some general
approval on the lin...@li... list (which is the
real place to discuss upstream PM improvements) and at the 2006 Linux
PM Summit.  But since then some objections were raised, and much of
the momentum evaporated for various reasons.  I see that Matthew
Locke, one of the original DPM guys, is still involved in pushing for
an expanded mechanism for general power parameters via his consulting
company, NomadGS; there's a presentation at
http://www.linuxdevices.com/files/article078/mlocke-elc2007-pm.ppt.pdf
.  This likely means there's a company in the embedded space funding
efforts to improve this.

There may be other DPM concepts that could find favor upstream in some
form or another.  The general ability for processes to express
relative power/performance requirements that are evaluted within the
absolute context of a "policy" that may be geared toward maximum
performance or toward maximum battery life conservation could be one
of them someday.  Power-policy-aware idle loops could be another.

It seems like a whole summit devoted to embedded PM could be in order,
in which the focus stays on what chipset vendors feel is important for
supporting their new, ever-more-complicated clocking and voltage
scaling architectures, and on what makers of battery-powered mobile
devices feel is needed to improve battery life.  And make sure the
desktop-oriented PM in-crowd buys into a reasonably concrete direction
for changes that can be made to support these.  It's tough work
arguing for this stuff and reaching a consensus.

-- 
Todd