Create /sys/power/policy_preference, giving user-space
the ability to express its preference for kernel based
power vs. performance decisions in a single place.
This gives kernel sub-systems and drivers a central place
to discover this system-wide policy preference.
It also allows user-space to not have to be updated
every time a sub-system or driver adds a new power/perf knob.
policy_preference has 5 levels, from max_performance
through max_powersave. Here is how 4 parts of the kernel
might respond to those 5 levels:
max_performance (unwilling to sacrifice any performance)
scheduler: default (optimized for performance)
cpuidle: disable all C-states except polling mode
ondemand: disable all P-states except max perf
msr_ia32_energy_perf_bias: 0 of 15
performance (care primarily about performance)
scheduler: default (optimized for performance)
cpuidle: enable all C-states subject to QOS
ondemand: all P-states, using no bias
msr_ia32_energy_perf_bias: 3 of 15
balanced (default)
scheduler: enable sched_mc_power_savings
cpuidle: enable all C-states subject to QOS
ondemand: all P-states, powersave_bias=5
msr_ia32_energy_perf_bias: 7 of 15
powersave (can sacrifice measurable performance)
scheduler: enable sched_smt_power_savings
cpuidle: enable all C-states, subject to QOS
ondemand: disable turbo mode, powersave_bias=10
msr_ia32_energy_perf_bias: 11 of 15
max_powersave (can sacrifice significant performance)
scheduler: enable sched_smt_power_savings
cpuidle: enable all C-states, subject to QOS
ondemand: min P-state (do not invoke T-states)
msr_ia32_energy_perf_bias: 15 of 15
Note that today Linux is typically operating in the mode
called "performance" above, rather than "balanced",
which is proposed to be the default. While a system
should work well if left in "balanced" mode, it is likely
that some users would want to use "powersave" when on
battery and perhaps shift to "performance" on A/C.
Please let me know what you think.
thanks,
Len Brown, Intel Open Source Technology Center
hi,
> From: Len Brown [[email protected]]
policy_preference has 5 levels, from max_performance
through max_powersave. Here is how 4 parts of the kernel
might respond to those 5 levels:
[levels description]
i do understand that you are mostly targetting acpi based systems, but even there, based on static leaks, it might not be always true that lower frequencies are correlated to higher power savings (or maybe i have misunderstood your draft - i am not so fluent in acpi)
> it is likely
> that some users would want to use "powersave" when on
> battery and perhaps shift to "performance" on A/C.
if we consider also the thermal envelope and the fact that "performance" might steal power from a charging battery, even ton A/C it might not be possible to settle down in one state permanently.
Or do you expect other mechanisms to intervene?
Cheers, igor-
On Jun 16, 2010, at 4:05 PM, Len Brown <[email protected]> wrote:
> Create /sys/power/policy_preference, giving user-space
> the ability to express its preference for kernel based
> power vs. performance decisions in a single place.
>
> This gives kernel sub-systems and drivers a central place
> to discover this system-wide policy preference.
> It also allows user-space to not have to be updated
> every time a sub-system or driver adds a new power/perf knob.
I would prefer documenting all the current knobs and adding them to pm-
utils so that pm-powersave knows about and can manage them. Once that
is done, creating arbitrary powersave levels should be fairly simple.
> policy_preference has 5 levels, from max_performance
> through max_powersave. Here is how 4 parts of the kernel
> might respond to those 5 levels:
>
> max_performance (unwilling to sacrifice any performance)
> scheduler: default (optimized for performance)
> cpuidle: disable all C-states except polling mode
> ondemand: disable all P-states except max perf
> msr_ia32_energy_perf_bias: 0 of 15
>
> performance (care primarily about performance)
> scheduler: default (optimized for performance)
> cpuidle: enable all C-states subject to QOS
> ondemand: all P-states, using no bias
> msr_ia32_energy_perf_bias: 3 of 15
>
> balanced (default)
> scheduler: enable sched_mc_power_savings
> cpuidle: enable all C-states subject to QOS
> ondemand: all P-states, powersave_bias=5
> msr_ia32_energy_perf_bias: 7 of 15
>
> powersave (can sacrifice measurable performance)
> scheduler: enable sched_smt_power_savings
> cpuidle: enable all C-states, subject to QOS
> ondemand: disable turbo mode, powersave_bias=10
> msr_ia32_energy_perf_bias: 11 of 15
>
> max_powersave (can sacrifice significant performance)
> scheduler: enable sched_smt_power_savings
> cpuidle: enable all C-states, subject to QOS
> ondemand: min P-state (do not invoke T-states)
> msr_ia32_energy_perf_bias: 15 of 15
>
> Note that today Linux is typically operating in the mode
> called "performance" above, rather than "balanced",
> which is proposed to be the default. While a system
> should work well if left in "balanced" mode, it is likely
> that some users would want to use "powersave" when on
> battery and perhaps shift to "performance" on A/C.
>
> Please let me know what you think.
>
> thanks,
> Len Brown, Intel Open Source Technology Center
> _______________________________________________
> linux-pm mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
On Thu, 17 Jun 2010, [email protected] wrote:
> i do understand that you are mostly targetting acpi based systems,
> but even there, based on static leaks, it might not be always true
> that lower frequencies are correlated to higher power savings
> (or maybe i have misunderstood your draft - i am not so fluent in acpi)
Right, my assertion is that ondemand deals only with P-states,
where, by defintion, the deeper the P-state the lower the voltage,
the higher the efficiency.
I assume that ondemand is not used to enable T-states
where the clock is throttled w/o lowering the voltage.
I put a note to try to make that clear under
max_powersave:
"ondemand: min P-state (do not invoke T-states)"
Of course it is also possible for a processor to do a poor job
implementing P-states and a great job optimizing idle states
such that race to idle were always a win. However, on such
a processor it would make more sense to simply disable P-states.
> > it is likely
> > that some users would want to use "powersave" when on
> > battery and perhaps shift to "performance" on A/C.
>
> if we consider also the thermal envelope and the fact that "performance"
> might steal power from a charging battery, even ton A/C it might not be
> possible to settle down in one state permanently.
>
> Or do you expect other mechanisms to intervene?
Typical laptop BIOS commonly implement a scheme where
they maximize performance on AC and bias towards saving energy
on DC.
That, of course, is just one example use-model.
Here Linux user-space can choose whatever policy
makes sense for them at run-time.
cheers,
-Len Brown, Intel Open Source Technology Center
> On Jun 16, 2010, at 4:05 PM, Len Brown <[email protected]> wrote:
>
> > Create /sys/power/policy_preference, giving user-space
> > the ability to express its preference for kernel based
> > power vs. performance decisions in a single place.
> >
> > This gives kernel sub-systems and drivers a central place
> > to discover this system-wide policy preference.
> > It also allows user-space to not have to be updated
> > every time a sub-system or driver adds a new power/perf knob.
>
> I would prefer documenting all the current knobs and adding them to pm-utils
> so that pm-powersave knows about and can manage them. Once that is done,
> creating arbitrary powersave levels should be fairly simple.
The idea here is to not require user-space to need updating
whenever a future knob is invented. We can do a great job
at documenting the past, but a poor job of documenting the future:-)
cheers,
Len Brown, Intel Open Source Technolgy Center
On Wed, Jun 16, 2010 at 2:05 PM, Len Brown <[email protected]> wrote:
> Create /sys/power/policy_preference, giving user-space
> the ability to express its preference for kernel based
> power vs. performance decisions in a single place.
>
> This gives kernel sub-systems and drivers a central place
> to discover this system-wide policy preference.
> It also allows user-space to not have to be updated
> every time a sub-system or driver adds a new power/perf knob.
>
This might be ok as a convince feature for userspace, but if that is
the sole intention, is 5 states enough? Are these values sufficient? I
can say at least for Android this will probably won't be as useful
(but perhaps on your platforms it makes sense).
As for a place for subsystems and drivers to check for what
performance mode you're in, do my driver how to check two places now?
Whats stopping someone from overriding cpufreq, or cpuidle? I might be
confused here (if I am someone please correct me) but isn't this
somewhat along he lines of pm runtime / pm qos if drivers want to
check what power / performance state the system is in?
-- Mike
> policy_preference has 5 levels, from max_performance
> through max_powersave. ?Here is how 4 parts of the kernel
> might respond to those 5 levels:
>
> max_performance (unwilling to sacrifice any performance)
> ? ? ? ?scheduler: default (optimized for performance)
> ? ? ? ?cpuidle: disable all C-states except polling mode
> ? ? ? ?ondemand: disable all P-states except max perf
> ? ? ? ?msr_ia32_energy_perf_bias: 0 of 15
>
> performance (care primarily about performance)
> ? ? ? ?scheduler: default (optimized for performance)
> ? ? ? ?cpuidle: enable all C-states subject to QOS
> ? ? ? ?ondemand: all P-states, using no bias
> ? ? ? ?msr_ia32_energy_perf_bias: 3 of 15
>
> balanced (default)
> ? ? ? ?scheduler: enable sched_mc_power_savings
> ? ? ? ?cpuidle: enable all C-states subject to QOS
> ? ? ? ?ondemand: all P-states, powersave_bias=5
> ? ? ? ?msr_ia32_energy_perf_bias: 7 of 15
>
> powersave (can sacrifice measurable performance)
> ? ? ? ?scheduler: enable sched_smt_power_savings
> ? ? ? ?cpuidle: enable all C-states, subject to QOS
> ? ? ? ?ondemand: disable turbo mode, powersave_bias=10
> ? ? ? ?msr_ia32_energy_perf_bias: 11 of 15
>
> max_powersave (can sacrifice significant performance)
> ? ? ? ?scheduler: enable sched_smt_power_savings
> ? ? ? ?cpuidle: enable all C-states, subject to QOS
> ? ? ? ?ondemand: min P-state (do not invoke T-states)
> ? ? ? ?msr_ia32_energy_perf_bias: 15 of 15
>
> Note that today Linux is typically operating in the mode
> called "performance" above, rather than "balanced",
> which is proposed to be the default. ?While a system
> should work well if left in "balanced" mode, it is likely
> that some users would want to use "powersave" when on
> battery and perhaps shift to "performance" on A/C.
>
> Please let me know what you think.
>
> thanks,
> Len Brown, Intel Open Source Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Thu, Jun 17, 2010 at 2:02 PM, Len Brown <[email protected]> wrote:
>
>> On Jun 16, 2010, at 4:05 PM, Len Brown <[email protected]> wrote:
>>
>> > Create /sys/power/policy_preference, giving user-space
>> > the ability to express its preference for kernel based
>> > power vs. performance decisions in a single place.
>> >
>> > This gives kernel sub-systems and drivers a central place
>> > to discover this system-wide policy preference.
>> > It also allows user-space to not have to be updated
>> > every time a sub-system or driver adds a new power/perf knob.
>>
>> I would prefer documenting all the current knobs and adding them to pm-utils
>> so that pm-powersave knows about and can manage them. Once that is done,
>> creating arbitrary powersave levels should be fairly simple.
>
>
> The idea here is to not require user-space to need updating
> whenever a future knob is invented. ?We can do a great job
> at documenting the past, but a poor job of documenting the future:-)
Well, I would suggest that the habit of not documenting what is
happening with power management in the kernel needs to change, then.
Having the documentation and example code for how to tweak the various
power management settings from userspace is inherently more flexible
than trying to expose a single knob from the kernel to userspace for
power management, with little loss of flexibility.
> cheers,
> Len Brown, Intel Open Source Technolgy Center
>
On Thu, 17 Jun 2010, Victor Lowther wrote:
> > The idea here is to not require user-space to need updating
> > whenever a future knob is invented. ?We can do a great job
> > at documenting the past, but a poor job of documenting the future:-)
>
> Well, I would suggest that the habit of not documenting what is
> happening with power management in the kernel needs to change, then.
Actually some of the knobs I showed in the examples
have been documented for *years*, yet are ignored
by user-space today. I don't want to insult user-space
programmers, but the reality is that simpler is usually better.
> Having the documentation and example code for how to tweak the various
> power management settings from userspace is inherently more flexible
> than trying to expose a single knob from the kernel to userspace for
> power management, with little loss of flexibility.
Yes, the ultimate in flexibility is to update user-space whenever
some new driver or new knob appears in the kernel. I'm not proposing
that ability be taken away. I'm proposing that in many cases it
is unnecessary.
The idea is to have the ability to add something to the
kernel and avoid the need to make any change to user-space.
thanks,
-Len Brown, Intel Open Source Technology Center
On Thu, 17 Jun 2010, Mike Chan wrote:
> On Wed, Jun 16, 2010 at 2:05 PM, Len Brown <[email protected]> wrote:
> > Create /sys/power/policy_preference, giving user-space
> > the ability to express its preference for kernel based
> > power vs. performance decisions in a single place.
> >
> > This gives kernel sub-systems and drivers a central place
> > to discover this system-wide policy preference.
> > It also allows user-space to not have to be updated
> > every time a sub-system or driver adds a new power/perf knob.
> >
>
> This might be ok as a convince feature for userspace, but if that is
> the sole intention, is 5 states enough?
>
> Are these values sufficient? I
> can say at least for Android this will probably won't be as useful
> (but perhaps on your platforms it makes sense).
Honestly, my first thought was to use 100 values -- a percentage.
But I got quickly taked out of it by people much wiser than me.
Consider that the vendors that are cleaning Linux's clock
on laptops seem quite content with 3 values at the user-interface.
So one might argue that 5 levels is already 66% more complexity
than needed:-)
Some suggested special case states, eg for HPC.
But those needs didn't fit into this simple power vs performance
continuum, and every consumer of this interface needs to undertand
every state, so adding special states would be a mistake.
The folks that do HPC and the folks that do embedded devices
are smart enough to tune their systems without using this
rather blunt instrument. They should continue to do so,
and this mechanism should not get in their way.
For example, if this mechanism is used to update powersave_bias
inside ondemand, but at the same time somebody tunes powersave_bias
by hand, the by-hand tuning must win.
> As for a place for subsystems and drivers to check for what
> performance mode you're in, do my driver how to check two places now?
> Whats stopping someone from overriding cpufreq, or cpuidle? I might be
> confused here (if I am someone please correct me) but isn't this
> somewhat along he lines of pm runtime / pm qos if drivers want to
> check what power / performance state the system is in?
pm runtime and pm qos are much bigger hammers, and this
mechanism is intended to complement them, not replace them.
Simply stated, this mechanism is intended just to give
a global hint of the user's power vs. performance preference
at a given time. There are places in the kernel and drivers
where power vs performance decisions are made with zero
concept of user preference, and this hint can help there.
Other parts of the kernel don't care, or have sufficient
information to make informed decisions, and thus they
simply wouldn't need to make use of this hint.
thanks,
Len Brown, Intel Open Source Technology Center
On Fri, Jun 18, 2010 at 12:56 AM, Len Brown <[email protected]> wrote:
> On Thu, 17 Jun 2010, Victor Lowther wrote:
>
>> > The idea here is to not require user-space to need updating
>> > whenever a future knob is invented. ?We can do a great job
>> > at documenting the past, but a poor job of documenting the future:-)
>>
>> Well, I would suggest that the habit of not documenting what is
>> happening with power management in the kernel needs to change, then.
>
> Actually some of the knobs I showed in the examples
> have been documented for *years*, yet are ignored
> by user-space today. ?I don't want to insult user-space
> programmers, but the reality is that simpler is usually better.
Let me explain where I am coming from, then. I maintain pm-utils, one
of the main low-level bodies of userspace code that concerns itself
with power management. I am currently in the process of standardizing
some of the more common power management tweaks so that they will work
in a cross distro manner, and know from this that the documentation we
have is badly fragmented -- if you know exactly what you are looking
for, you can google or grep for it, but if you do not, there is no
easy way to find a list of all the power management settings you can
tune.
>> Having the documentation and example code for how to tweak the various
>> power management settings from userspace is inherently more flexible
>> than trying to expose a single knob from the kernel to userspace for
>> power management, with little loss of flexibility.
>
> Yes, the ultimate in flexibility is to update user-space whenever
> some new driver or new knob appears in the kernel. ?I'm not proposing
> that ability be taken away. ?I'm proposing that in many cases it
> is unnecessary.
I disagree. Most of userspace does not care about how the system is
trying to save power. I maintain one that does, and I do not like the
idea of adding another knob whose entire purpose is to map other,
already existing knobs onto a line, especially when we can do that in
userspace easily enough if anyone actually wants it.
> The idea is to have the ability to add something to the
> kernel and avoid the need to make any change to user-space.
Userspace in this case consists mainly of
acpi-scripts/pm-utils/laptop-mode-tools, upower,
g-p-m/kpowersave/x-p-m, and X. I can only speak for pm-utils, but the
model pm-utils, acpi-scripts, and laptop-mode-tools use does not map
to your proposed knob at all. We use a two-state model -- either we
are on AC power and use the kernel's default power state, or we are on
battery power and set power management to a set of distro or user
chosen set of parameters. I am working on making pm-utils contain
some predefined powersaving policies, but I do not expect them to
change the two-state model much more than changing which power
management tweaks are used in the on-ac and on-battery states.
> thanks,
> -Len Brown, Intel Open Source Technology Center
>
* Victor Lowther <[email protected]> [2010-06-17 11:14:50]:
>
>
>
>
> On Jun 16, 2010, at 4:05 PM, Len Brown <[email protected]> wrote:
>
> >Create /sys/power/policy_preference, giving user-space
> >the ability to express its preference for kernel based
> >power vs. performance decisions in a single place.
> >
> >This gives kernel sub-systems and drivers a central place
> >to discover this system-wide policy preference.
> >It also allows user-space to not have to be updated
> >every time a sub-system or driver adds a new power/perf knob.
>
> I would prefer documenting all the current knobs and adding them to
> pm-utils so that pm-powersave knows about and can manage them. Once
> that is done, creating arbitrary powersave levels should be fairly
> simple.
Hi Len,
Reading through this thread, I prefer the above recommendation. We
have three main dimensions of (power savings) control (cpufreq,
cpuidle and scheduler) and you are combining them into a single policy
in the kernel. The challenges are as follows:
* Number of policies will always limit flexibility
* More dimensions of control will be added in future and your
intention is to transparently include them within these defined
polices
* Even with the current implementations, power savings and performance
impact widely vary based on system topology and workload. There is
no easy method to define modes such that one mode will _always_
consume less power than the other
* Each subsystem can override the policy settings and create more
combinations anyway
Your argument is that these modes can serve as a good default and allow
the user to tune the knobs directly for more sophisticated policies.
But in that case all kernel subsystem should default to the balanced
policy and let the user tweak individual subsystems for other modes.
On the other hand having the policy definitions in user space allows
us to create more flexible policies by considering higher level
factors like workload behavior, utilization, platform features,
power/thermal constraints etc.
--Vaidy
[snip]
On Saturday, June 19, 2010, Vaidyanathan Srinivasan wrote:
> * Victor Lowther <[email protected]> [2010-06-17 11:14:50]:
>
> >
> >
> >
> >
> > On Jun 16, 2010, at 4:05 PM, Len Brown <[email protected]> wrote:
> >
> > >Create /sys/power/policy_preference, giving user-space
> > >the ability to express its preference for kernel based
> > >power vs. performance decisions in a single place.
> > >
> > >This gives kernel sub-systems and drivers a central place
> > >to discover this system-wide policy preference.
> > >It also allows user-space to not have to be updated
> > >every time a sub-system or driver adds a new power/perf knob.
> >
> > I would prefer documenting all the current knobs and adding them to
> > pm-utils so that pm-powersave knows about and can manage them. Once
> > that is done, creating arbitrary powersave levels should be fairly
> > simple.
>
> Hi Len,
>
> Reading through this thread, I prefer the above recommendation.
It also reflects my opinion quite well.
> We have three main dimensions of (power savings) control (cpufreq,
> cpuidle and scheduler) and you are combining them into a single policy
> in the kernel.
There's more than that, because we're in the process of adding runtime PM
features to I/O device drivers.
> The challenges are as follows:
>
> * Number of policies will always limit flexibility
> * More dimensions of control will be added in future and your
> intention is to transparently include them within these defined
> polices
> * Even with the current implementations, power savings and performance
> impact widely vary based on system topology and workload. There is
> no easy method to define modes such that one mode will _always_
> consume less power than the other
> * Each subsystem can override the policy settings and create more
> combinations anyway
>
> Your argument is that these modes can serve as a good default and allow
> the user to tune the knobs directly for more sophisticated policies.
> But in that case all kernel subsystem should default to the balanced
> policy and let the user tweak individual subsystems for other modes.
>
> On the other hand having the policy definitions in user space allows
> us to create more flexible policies by considering higher level
> factors like workload behavior, utilization, platform features,
> power/thermal constraints etc.
The policy_preference levels as proposed are also really arbitrary and they
will usually mean different things on different systems. If the interpretation
of these values is left to device drivers, then (for example) different network
adapter drivers may interpret "performance" differently and that will lead to
different types of behavior depending on which of them is used. I think we
should rather use interfaces that unambiguously tell the driver what to do.
Thanks,
Rafael
On Wed, Jun 16, 2010 at 05:05:26PM -0400, Len Brown wrote:
> Create /sys/power/policy_preference, giving user-space
> the ability to express its preference for kernel based
> power vs. performance decisions in a single place.
>
> policy_preference has 5 levels, from max_performance
> through max_powersave. Here is how 4 parts of the kernel
> might respond to those 5 levels:
In theory this makes sense. We have been toying with something
like this, but the difficulty is that outside of benchmarking
environment, it is hard to figure out what mode to set when.
Also, the impact could be different for different workloads.
We should probably have a broader discussion around this
with data - I will share some measurements on impact
of such power modes.
> max_performance (unwilling to sacrifice any performance)
> scheduler: default (optimized for performance)
> cpuidle: disable all C-states except polling mode
> ondemand: disable all P-states except max perf
> msr_ia32_energy_perf_bias: 0 of 15
>
> performance (care primarily about performance)
> scheduler: default (optimized for performance)
> cpuidle: enable all C-states subject to QOS
> ondemand: all P-states, using no bias
> msr_ia32_energy_perf_bias: 3 of 15
>
> balanced (default)
> scheduler: enable sched_mc_power_savings
> cpuidle: enable all C-states subject to QOS
> ondemand: all P-states, powersave_bias=5
> msr_ia32_energy_perf_bias: 7 of 15
Would there be sufficient difference between performance
and balanced ?
>
> powersave (can sacrifice measurable performance)
> scheduler: enable sched_smt_power_savings
> cpuidle: enable all C-states, subject to QOS
> ondemand: disable turbo mode, powersave_bias=10
> msr_ia32_energy_perf_bias: 11 of 15
>
> max_powersave (can sacrifice significant performance)
> scheduler: enable sched_smt_power_savings
> cpuidle: enable all C-states, subject to QOS
> ondemand: min P-state (do not invoke T-states)
> msr_ia32_energy_perf_bias: 15 of 15
Thanks
Dipankar