mbox series

[RFC,0/7] sched/cpufreq: Make schedutil energy aware

Message ID 20190508174301.4828-1-douglas.raillard@arm.com (mailing list archive)
Headers show
Series sched/cpufreq: Make schedutil energy aware | expand

Message

Douglas RAILLARD May 8, 2019, 5:42 p.m. UTC
From: Douglas RAILLARD <douglas.raillard@arm.com>

Make schedutil cpufreq governor energy-aware.

- patch 1 introduces a function to retrieve a frequency given a base
  frequency and an energy cost margin.
- patch 2 links Energy Model perf_domain to sugov_policy.
- patch 3 updates get_next_freq() to make use of the Energy Model.
- patch 4 moves a static function around in cpufreq_schedutil.c to make
  it available for subsequent patch.
- patch 5 updates sugov_cpu_is_busy() to make it useable for shared
  cpufreq policies.
- patch 6 improves sugov_cpu_is_busy() to avoid some pitfalls when used
  from shared policies.
- patch 7 makes use of sugov_cpu_is_busy() for frequency selection of
  shared cpufreq policies.

The benefits of using the EM in schedutil are twofold:

1) Selecting the highest possible frequency for a given cost. Some
   platforms can have lower frequencies that are less efficient than
   higher ones, in which case they should be skipped for most purposes.
   They can still be useful to give more freedom to thermal throttling
   mechanisms, but not under normal circumstances.
   note: the EM framework will warn about such OPPs "hertz/watts ratio
   non-monotonically decreasing"

2) Drive the frequency selection with power in mind, in addition to
   maximizing the utilization of the non-idle CPUs in the system.

Point 1) is implemented in "PM: Introduce em_pd_get_higher_freq()" and
enabled in schedutil by
"sched/cpufreq: Hook em_pd_get_higher_power() into get_next_freq()".

Point 2) is enabled in
"sched/cpufreq: Boost schedutil frequency ramp up". It allows using
higher frequencies when a CPU is "busy" in the policy, reusing the
existing sugov_cpu_is_busy() schedutil heuristic.  "busy" is defined
here as not having any idle time since the last increase in frequency.
The benefits of that are:

* Boosting the frequency when it (seems) needed by a CPU to finish its
  allocated work. That shortens the frequency ramp up duration, which in
  turns allows the utilization signal to reach stable values quicker.
  Since the allowed frequency boost is bounded in energy, it will behave
  consistently across platforms, regardless of the OPP cost range.

* The boost is only transient, and should not impact a lot the energy
  consumed of workloads with very stable utilization signals.


This has been ligthly tested with a rtapp task ramping from 10% to 75%
utilisation on a big core. Improvements in frequency ramp-up time are
somehow diminished by the shape of the utilisation signal, which gives a
big oscillation to the signal after a fast ramp up with idle time. It
however improves the time it takes to reach the final frequency, but
some activations are still missed due to strong frequency decrease right
after ramping up.

Douglas RAILLARD (7):
  PM: Introduce em_pd_get_higher_freq()
  sched/cpufreq: Attach perf domain to sugov policy
  sched/cpufreq: Hook em_pd_get_higher_power() into get_next_freq()
  sched/cpufreq: Move up sugov_cpu_is_busy()
  sched/cpufreq: sugov_cpu_is_busy for shared policy
  sched/cpufreq: Improve sugov_cpu_is_busy accuracy
  sched/cpufreq: Boost schedutil frequency ramp up

 include/linux/energy_model.h     |  48 +++++++++++
 kernel/sched/cpufreq_schedutil.c | 136 +++++++++++++++++++++++++++----
 2 files changed, 166 insertions(+), 18 deletions(-)

Comments

Viresh Kumar May 13, 2019, 7:12 a.m. UTC | #1
On Wed, May 8, 2019 at 11:57 PM <douglas.raillard@arm.com> wrote:
>
> From: Douglas RAILLARD <douglas.raillard@arm.com>
>
> Make schedutil cpufreq governor energy-aware.

Hi Douglas,

I was wondering on why the cpufreq maintainers weren't cc'd for this set and
then I noticed that get_maintainers doesn't report us at all for schedutil :(

I have sent a patch to fix that, but please include us as well in the
future even
if get_maintainers doesn't report us :)

--
viresh
Douglas RAILLARD May 13, 2019, 1:52 p.m. UTC | #2
Hi Viresh, Rafael,

On 5/13/19 8:12 AM, Viresh Kumar wrote:
> On Wed, May 8, 2019 at 11:57 PM <douglas.raillard@arm.com> wrote:
>>
>> From: Douglas RAILLARD <douglas.raillard@arm.com>
>>
>> Make schedutil cpufreq governor energy-aware.
> 
> Hi Douglas,
> 
> I was wondering on why the cpufreq maintainers weren't cc'd for this set and
> then I noticed that get_maintainers doesn't report us at all for schedutil :(
>
> I have sent a patch to fix that, but please include us as well in the
> future even
> if get_maintainers doesn't report us :)

Looks like it was a mix of me not checking my checklist and get_maintainers
not catching it, I'll make sure both of you are in CC next time :)

> 
> --
> viresh

Thanks,
Douglas