Experimental power saving profile support branch in pm-utils

Experimental power saving profile support branch in pm-utils

[Victor Lowther]

The latest release of pm-utils (1.4.0) added some default hooks for
helping conserve power.  Based on the recent thread on linux-pm
proposing a /sys/power/policy_preference knob, I decided to implement
support for setting powersave profiles in pm-utils.  From the git
logs:

Add support for powersave policies.

    A powersave policy is a pm-utils configuration file that the pm-powersave
    command treats specially.  You can use it to define various levels of power
    savings available to a system by changing the environment variables the
    power.d hooks run with, and by blacklisting any hooks you do not want to
    use at any given level.

    pm-powersave will look in /etc/pm/powersave and /usr/lib/pm-utils/powersave
    in that order, and policy settings override any other variables or hook
    overrides set via other methods. If no policies are in use, pm-powersave
    considers itself to be in the default policy, and will fall back to the
    usual settings for the powersave hooks.

    You can set a powersave policy with

    pm-powersave --(ac|battery)-policy=<policy>

    or

    pm-powersave --(ac|battery)-policy <policy>

    Setting a policy in this fashion does not actually apply the policy.

    You can get the current powersave policy by running

    pm-powersave --(ac|battery)-policy

    You can list all the policies with

    pm-powersave --list-policies

    Policies should not know or care about the actual power source the system
    is using -- it is expected that some users will want to use the same policy
    no matter what power source is being used.

    The "default" policy is shorthand for the way pm-powersave will behave
    in the absence of a defined policy for either the ac or battery
power states.
    When on AC power, it will set everything back to the kernel defaults.
    On battery power, it will tune things according to the powersave
hook defaults.

    If you want to apply a powersave policy directly, just run

    pm-powersave <policyname>

    and the policy you passed will be immediatly applied without changing the
    preferred policy for the current power state.

You can get the branch that implements this from
http://cgit.freedesktop.org/pm-utils/ in the powersave-policies
branch.

If there is a power savings knob that we should handle but do not,
please either send a patch to the pm-utils mailing list or email me
directly.

If there are any ideas about setting good cross-distro defaults, I am
interested about them.

Regards,
   Victor Lowther

Re: Experimental power saving profile support branch in pm-utils

[Ben Gamari]

On Fri, 25 Jun 2010 23:44:22 -0500, Victor Lowther <victor.lowther@gmail.com> wrote:
> The latest release of pm-utils (1.4.0) added some default hooks for
> helping conserve power.  Based on the recent thread on linux-pm
> proposing a /sys/power/policy_preference knob, I decided to implement
> support for setting powersave profiles in pm-utils.  From the git
> logs:
> 
I'm really confused. This seems like the polar opposite of the direction
we have been saying we should be taking. The argument has been strongly
made (Matthew Garrett comes to mind, but there are no doubt others) in
the past that the concept of a power profile is fundamentally
broken. Instead we should _always_ be trying to save power. Thankfully
there are only very few cases where saving power and delivering good
performance are at stake. In general, the faster we can get our work
done, the longer we can remain in low-power states.  Moreover, hardware
is only getting better at saving power while minimally affecting
operation.

Thus, I pose the question: do we really want this sort of explicit
control in the user-space? Even if we do, I far from convinced that the
policy_preference model is a sound way to expose this preference to the
user. The 5 levels as layed out in the proposal seem awfully arbitrary
and really don't express the full gamut of preferences that a user might
hold.

- Ben

Re: Experimental power saving profile support branch in pm-utils

[Victor Lowther]

On Sat, Jun 26, 2010 at 12:08 AM, Ben Gamari <bgamari@gmail.com> wrote:
> On Fri, 25 Jun 2010 23:44:22 -0500, Victor Lowther <victor.lowther@gmail.com> wrote:
>> The latest release of pm-utils (1.4.0) added some default hooks for
>> helping conserve power.  Based on the recent thread on linux-pm
>> proposing a /sys/power/policy_preference knob, I decided to implement
>> support for setting powersave profiles in pm-utils.  From the git
>> logs:
>>
> I'm really confused. This seems like the polar opposite of the direction
> we have been saying we should be taking. The argument has been strongly
> made (Matthew Garrett comes to mind, but there are no doubt others) in
> the past that the concept of a power profile is fundamentally
> broken. Instead we should _always_ be trying to save power. Thankfully
> there are only very few cases where saving power and delivering good
> performance are at stake.

That does not remove the need to manage those cases, and different
users will have different ideas about what an acceptable tradeoff
between power and performance is.

> In general, the faster we can get our work
> done, the longer we can remain in low-power states.  Moreover, hardware
> is only getting better at saving power while minimally affecting
> operation.

For hardware like CPUs and memory controllers, this is the case.  It
is less so for PCIe ASPM, SATA/SAS ALPM, and wireless power
management, and not really the case at all for spinning down your hard
drive.

Moreover, an important part of saving power involves tuning the
virtual memory subsystem and the filesystems to minimize disk
I/O,trading how long dirty data remains in memory for power savings.
Different users will have different ideas about what is acceptable,
and it is not something that is really autotunable.

> Thus, I pose the question: do we really want this sort of explicit
> control in the user-space? Even if we do, I far from convinced that the
> policy_preference model is a sound way to expose this preference to the
> user. The 5 levels as layed out in the proposal seem awfully arbitrary
> and really don't express the full gamut of preferences that a user might
> hold.

That is why I want to make it easy to create and manage arbitrary
policies in userspace as opposed to having it in kernelspace where it
is harder to modify according to what the end user desires.

> - Ben
>