An embedded-Linux power-management framework

An embedded-Linux power-management framework

[Robert C. Paulsen Jr.]

An embedded-Linux power-management framework
============================================

A dynamic power management framework for Linux is necessary to support the
flexible and aggressive power management policies made possible by the new
class of dynamic voltage- and frequency-scalable embedded processors including
the IBM PowerPC 405LP and the Intel XScale PXA210 and PXA250.

We have recently started work in this and would appreciated feedback on the
direction we are headed, summarized as a set of requirements below. Once
we have a start at a specification and some code we will put everything on
Sourceforge as an Open Source project. Please let us know what you think!

Requirements
============

Since CPU power typically increases as the cube of voltage while CPU frequency
scales linearly with voltage, very significant power savings can be achieved by
selecting the correct operating point for the current application set.  For
example, playing an MP3 with madplay only takes about 30 Mhz of the 405LP CPU.
By running the system at the lowest operating point sufficient to play the MP3
(100 MHz @ 1.0 V) vs. the highest possible operating point (266 MHz @ 1.8 V) an
immediate system power reduction (CPU + memory) of 40% is realized.  Since the
405LP can scale CPU and bus frequencies with an OS overhead in the tens of
microseconds, it also makes sense to scale back the CPU and bus during idle.
The power reduction between idling at 33 MHz and 100 Mhz is about 20% in one
system, and is significant because scaling back the bus frequency also reduces
the SDRAM power.  The low overhead required to do this scaling means we can
achieve these power savings without impacting interrupt response time too much.
Even with more power-hungry applications like MPEG-4 playback, on the 405LP
we've found that voltage- and frequency-scaling the system to a low-power state
during the inter-frame gaps (i.e. 30 times per second) can reduce system power
consumption (extends battery life) by 10%, and has no visible impact on the
video playback.

In addition, devices using these newer processors continue to support the
traditional static power management using sleep, hibernate, (etc.)
power-saving states.

In summary, the requirements for a Linux power-management framework are:

1. Support dynamic power management by taking advantage of the dynamic
   scaling capabilities of new hardware.

2. Support traditional static power management.

3. Both static and dynamic power management need to be supported with a
   Linux-specific, BIOS-independent, architecture-independent design.
   This consolidated design must account for interactions between static
   and dynamic power management.

4. Support embedded systems with uni-processors and symmetric or
   asymmetric multiprocessors.

5. Support pluggable power management policies.  This allows end-users to
   install applications that benefit from unique power policies and
   supports the following requirement.

6. Allow applications to both choose and provide hints to power policies.

Thanks!

  From:
    Hollis Blanchard <hollis-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org> (IBM) 
    Bishop Brock <bcbrock-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> (IBM) 
    Matthew Locke <mlocke-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org> (MontaVista)
    Mark Orvek <morvek-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org> (MontaVista)
    Robert Paulsen <rpaulsen-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> (IBM)
    Karthick Rajamani <karthick-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> (IBM)

-- 
Robert C. Paulsen, Jr.
robert-J3gkRE/D7QA8RZtLRHdnRF6hYfS7NtTn@public.gmane.org


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Alan Cox]

Take a look at cpufreq. The processor speed/voltage side is a solved
problem with working code for x86 and ARM processors including the
framework to adjust other devices. For example on ARM you have to frob
with the RAM clocks. Cpufreq deals with it nicely both from user and
kernel sides

In terms of per process settings please read US patent 6,298,448.

Suggstions on how t work around it are welcomed



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Hollis Blanchard]

On Fri, 2002-08-02 at 14:11, Alan Cox wrote:
> Take a look at cpufreq. The processor speed/voltage side is a solved
> problem with working code for x86 and ARM processors including the
> framework to adjust other devices. For example on ARM you have to frob
> with the RAM clocks. Cpufreq deals with it nicely both from user and
> kernel sides

cpufreq seems entirely aimed at CPU frequency control. Lowering your
frequency will linearly decrease power, but will also linearly extend
the duration of your task. Therefore it makes a lot of sense to lower
voltage in addition to frequency. Some hardware drivers supported in the
cpufreq code already scale down voltage as allowed by frequency
reduction.

However, it also makes sense to decrease frequency independent of
voltage, since voltage transitions can have higher latency than
frequency transitions. The idle task is a great place to lower frequency
only, since you're not doing anything anyways (you're not extending the
running time of a meaningful task), but you may not want to incur the
overhead of a voltage transition every time you come in and out of it.

There are also other frequencies that can affect power consumption, such
as PLB (processor local bus) frequency.

There are situations (especially in dedicated-purpose devices running
only a few hand-written applications) in which it helps to change some
of these values without changing the others. Changing them all according
to a single variable (CPU core frequency) could be very limiting. To my
knowledge the cpufreq code also does not allow for this flexibility, but
certainly it would be nice to add it.

(Perhaps we should continue the thread on linux-pm-devel or cpufreq
instead of cross-posting everywhere?)

-Hollis



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Alan Cox]

On Fri, 2002-08-02 at 19:20, Hollis Blanchard wrote:
> There are situations (especially in dedicated-purpose devices running
> only a few hand-written applications) in which it helps to change some
> of these values without changing the others. Changing them all according
> to a single variable (CPU core frequency) could be very limiting. To my
> knowledge the cpufreq code also does not allow for this flexibility, but
> certainly it would be nice to add it.

So improve the cpufreq code to be a bit more controllable. Its the right
framework. It also needs a littlw tweaking for the cases where we change
STPCLK on x86's.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Johnathan Hicks]

Alan Cox wrote:
> On Fri, 2002-08-02 at 19:20, Hollis Blanchard wrote:
> 
>>There are situations (especially in dedicated-purpose devices running
>>only a few hand-written applications) in which it helps to change some
>>of these values without changing the others. Changing them all according
>>to a single variable (CPU core frequency) could be very limiting. To my
>>knowledge the cpufreq code also does not allow for this flexibility, but
>>certainly it would be nice to add it.
> 
> 
> So improve the cpufreq code to be a bit more controllable. Its the right
> framework. It also needs a littlw tweaking for the cases where we change
> STPCLK on x86's.

Are you sure that cpufreq should be tweaked to manage STPCLK? Would it not 
make more sence to suck cpufreq into ACPI and call it during Tx (throttling) 
states if applicable? Of course I realise that might not be allowed by the 
ACPI spec, but some combination of cqufreq and the Tx states is a good idea... 
and optional for the user.

--John

--John




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Alan Cox]

On Sat, 2002-08-03 at 01:48, Johnathan Hicks wrote:
> Are you sure that cpufreq should be tweaked to manage STPCLK? Would it not 
> make more sence to suck cpufreq into ACPI and call it during Tx (throttling) 
> states if applicable? Of course I realise that might not be allowed by the 
> ACPI spec, but some combination of cqufreq and the Tx states is a good idea... 
> and optional for the user.

It may make sense on a box with ACPI, but most boxes that are heavily
STPCLK managed are older. The Athlon one seems to be less interesting
than the others (btw - seems you can mix stpclk with the other features
you just have to turn stpclk back off before idling)

On a K5/K6/486/.. STPCLK is basically your entire power management
barring what lurks on the PCI devices - which can save a suprising
amount of power too. I've been playing (not very successfully at the
moment) at dropping my video card into D3 when screenblanking




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Johnathan Hicks]

Alan Cox wrote:
> It may make sense on a box with ACPI, but most boxes that are heavily
> STPCLK managed are older. The Athlon one seems to be less interesting
> than the others (btw - seems you can mix stpclk with the other features
> you just have to turn stpclk back off before idling)

Ah yes, I had forgotten about the older hardware, but I thought all they had 
was HLT. About the Athlon case, STPCLK is used for all the power management 
that I can think of except HLT. Feel free to correct me here if I'm wrong.

> On a K5/K6/486/.. STPCLK is basically your entire power management
> barring what lurks on the PCI devices - which can save a suprising
> amount of power too. I've been playing (not very successfully at the
> moment) at dropping my video card into D3 when screenblanking

What kind of delay would that cause when restoring the state of the card? I 
would hope not that great of a delay as this kind of action is one that should 
be expected.

--John




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Alan Cox]

On Fri, 2002-08-02 at 19:20, Hollis Blanchard wrote:
> frequency transitions. The idle task is a great place to lower frequency
> only, since you're not doing anything anyways (you're not extending the
> running time of a meaningful task), but you may not want to incur the
> overhead of a voltage transition every time you come in and out of it.
> 

The idle task should almost never run on a properly power managed system
because if we are getting voltage reductions we want to reduce the
frequency so that we are not quite idle as that saves us more power than
idling. This is also effectively true for clock only scaling because
very few of them have a "stopped" mode so their is a ceiling of minimal
power consumption we want to rest at as much as possible




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Pavel Machek]

Hi!

> Take a look at cpufreq. The processor speed/voltage side is a solved
> problem with working code for x86 and ARM processors including the
> framework to adjust other devices. For example on ARM you have to frob
> with the RAM clocks. Cpufreq deals with it nicely both from user and
> kernel sides
> 
> In terms of per process settings please read US patent 6,298,448.

Hmm.. like moving outside U.S.? ;-)

[OTOH, IBM might be big enough to buy the pattent and put it in PD or
(preferably) prove there was prior work / prove it was trivial and
invalidate that.]
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

An embedded-Linux power-management framework

[Bishop Brock]

>From: Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
>Subject: Re: [ACPI] An embedded-Linux power-management framework
>Date: 02 Aug 2002 20:11:17 +0100

> Take a look at cpufreq. The processor speed/voltage side is a solved
> problem with working code for x86 and ARM processors including the
> framework to adjust other devices. For example on ARM you have to frob
> with the RAM clocks. Cpufreq deals with it nicely both from user and
> kernel sides

Processor speed and voltage setting are only two dimensions of the problem
for current and future generations of embedded processors.  The PowerPC
405LP supports 6 somewhat independent parameters that affect the power
consumption of the system: Core voltage, CPU frequency, Memory Bus
Frequency,
On-board peripheral bus frequency, External peripheral bus frequency, and
LCD
pixel clock frequency. The next generation of processors will take this
even
further: They will support multiple internal voltage planes, asymmetric
multiprocessing (cf. TI OMAP architecture) with independent voltage control
and clocking, and advanced clocking schemes to maximize the potential for
dynamic power management.  We will be able to do amazing things with
minuscule amounts of energy, but only if the OS supports the flexibility
inherent in the underlying hardware architectures.

We are proposing a scalable solution that naturally extends the
capabilities of cpufreq. We encapsulate all of the mutually constrained
physical and abstract parameters of a power management policy into
a system-dependent object called an "operating point", and propose
standard ways to manipulate operating points and sets of operating points.
This mechanism will be integrated with the device model in such a way
that as devices come on and off line, the optimum operating point is always
available.

We also add another dimension not present in the current solution, i.e.,
kernel control of dynamic power management at critical points in the
OS, particularly the entry and exit of the idle (halt) state, consistent
with policies defined in advance.  As we noted in the original posting,
significant system-wide energy savings are possible by rapidly scaling
frequencies during even short idle periods, and only the OS has the
visibility required to actively manage these events.

> In terms of per process settings please read US patent 6,298,448.

> Suggstions on how t work around it are welcomed

The following comments must not be construed as a legal position of
the IBM Corporation, or the legal opinion of any IBM attorney.

We have discussed this patent with our IP attorneys.  Those of
us developing this proposal are operating under the working
assumption that this patent does not preclude us from publishing
our code, and will not preclude anyone from executing our code
on any IBM processors.  However, prior to any release of
code to Open Source, we will go through a legal review process where
these issues will be closed to the satisfaction of IBM and our
Linux Distribution partners.

As an aside, my colleagues and I have doubts about the enforceability
of the patent in any case, due to extensive prior art before the
filing date.


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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Alan Cox]

On Sat, 2002-08-03 at 02:28, Bishop Brock wrote:m
> We are proposing a scalable solution that naturally extends the
> capabilities of cpufreq. We encapsulate all of the mutually constrained
> physical and abstract parameters of a power management policy into
> a system-dependent object called an "operating point", and propose
> standard ways to manipulate operating points and sets of operating points.
> This mechanism will be integrated with the device model in such a way
> that as devices come on and off line, the optimum operating point is always
> available.

Each operating point being some appropriate categorised and chip
supported combination of power state ? So for something simple like a
mobile K6 we'd have something like

			Full on
			STPCLK and Powernow combinations
			hlt

> We also add another dimension not present in the current solution, i.e.,
> kernel control of dynamic power management at critical points in the
> OS, particularly the entry and exit of the idle (halt) state, consistent

You install your own idle handler to replace the default one - there are
some examples of people doing this already. The amd76x_pm code for
example installs its own idle handler which is needed because both
processors must be idle to drop into most powersaving states.

> with policies defined in advance.  As we noted in the original posting,
> significant system-wide energy savings are possible by rapidly scaling
> frequencies during even short idle periods, and only the OS has the
> visibility required to actively manage these events.

Clearly true



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

An embedded-Linux power-management framework

[Bishop Brock]

From: Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Subject: Re: [ACPI] An embedded-Linux power-management framework
Date: 03 Aug 2002 00:31:10 +0100

On Fri, 2002-08-02 at 19:20, Hollis Blanchard wrote:
>> frequency transitions. The idle task is a great place to lower frequency
>> only, since you're not doing anything anyways (you're not extending the
>> running time of a meaningful task), but you may not want to incur the
>> overhead of a voltage transition every time you come in and out of it.
>>

> The idle task should almost never run on a properly power managed system
> because if we are getting voltage reductions we want to reduce the
> frequency so that we are not quite idle as that saves us more power than
> idling. This is also effectively true for clock only scaling because
> very few of them have a "stopped" mode so their is a ceiling of minimal
> power consumption we want to rest at as much as possible

I assume you're talking about systems with more-or-less continuous
workloads;
the examples most often used in academic research are media players.
You've asserted  the conventional wisdom about dynamic power management
which I challenge
as being 1) system and application dependent, and 2) unachievable.

On the first point, we're concerned with system-wide power management,
which includes the
memory subsystem.  Our processors are so power-efficient today that we burn
more power
in the memory than in the CPU core.  An idle system can greatly reduce
memory power by
reducing the memory clock frequency, and/or self-refreshing all or part of
the memory.  Depending
on the application and system design, it may be more power-efficient to
finish the application
quickly and power down the memory, rather than trying to extend the run
time of the application
to just meet a deadline, which requires continuously running the memory at
high frequencies.

On the second point, we all dream of finding just the right operating point
that allows our
media applications to finish just in time with minimum energy, but are
always disappointed.
Power states are quantized, first by the data sheet of the processor which
will list at most a few
fully characterized voltage operating points, and second by the clocking
subsystems which will
limit the range of allowable frequency scaling.  Due to normal variations
in media workloads,
a power management policy that tries to guarantee high fidelity in the
playback will naturally
need to include a provision for headroom in the selection of the operating
point.  These
three factors: workload variability, a fixed list of operating points and a
conservative
power management policy lead to slack, i.e., idle time.  Our proposal
allows the system to
capture the slack by aggressively idling the processor for short periods,
e.g., between video
frames, without any effect on the application, and with significant energy
reduction.

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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Alan Cox]

On Sat, 2002-08-03 at 03:29, Bishop Brock wrote:
> On the first point, we're concerned with system-wide power management,
> which includes the
> memory subsystem.  Our processors are so power-efficient today that we burn
> more power

IBM's may be, but this isnt an IBM PPC specific operating system
project. If the servers are for example AMD dual Athlons or 1U Pentium
IV rack boxes then it -really- begins to matter. To put the scale of
this into perspective on x86 - I can run another entire system in the
power differential between idle and full running dual athlon.

In some respects the Athlon is closer to what you claim since there is a
chunk of power saving that occurs only when both cpus are stopped.

I'm not arguing against your claim. I want to be sure we can support
both.behaviours.

> power management policy lead to slack, i.e., idle time.  Our proposal
> allows the system to
> capture the slack by aggressively idling the processor for short periods,
> e.g., between video
> frames, without any effect on the application, and with significant energy
> reduction.

Some processes show short interactive behaviours. You can quantify and
measure that, indeed the scheduler already has an extremely good idea
what is and is not an interactive process that will execute short bursts
then sleep a lot. Whether that is enough I don't know.

Alan



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: An embedded-Linux power-management framework

[Alan Cox]

On Sat, 2002-08-03 at 15:50, Johnathan Hicks wrote:
> What kind of delay would that cause when restoring the state of the card? I 
> would hope not that great of a delay as this kind of action is one that should 
> be expected.

Assuming the card takes a small bit of time to reconfigure then the D3
transition timings for PCI are 200uS for D2 and about 1/100th of a
second for D3.

Some cards can take a lot longer to reconfigure if there are PLL's and
the like or busses to bring back up



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf