[v2,0/6] consolidate and cleanup CPU capacity

Message

Vincent Guittot Oct. 9, 2023, 10:36 a.m. UTC

This is the 1st part of consolidating how the max compute capacity is
used in the scheduler and how we calculate the frequency for a level of
utilization.

Fix some unconsistancy when computing frequency for an utilization. There
can be a mismatch between energy model and schedutil.

Next step will be to make a difference between the original
max compute capacity of a CPU and what is currently available when
there is a capping applying forever (i.e. seconds or more).


Changes since v1:
- Fix typos
- Added changes in cpufreq to use arch_scale_freq_ref() when calling
  arch_set_freq_scale (patch 3).
- arch_scale_freq_ref() is always defined and returns 0 (as proposed
  by Ionela) when not defined by the arch. This simplifies the code with
  the addition of patch 3.
- Simplify Energy Model which always uses arch_scale_freq_ref(). The
  latter returns 0 when not defined by arch instead of last item of the 
  perf domain. This is not a problem because the function is only defined
  for compilation purpose in this case and we don't care about the
  returned value. (patch 5)
- Added changes in cppc cpufreq to set capacity_ref_freq (patch 6)
- Added reviewed tag for patch 1 which got a minor change but not for
  others as I did some changes which could make previous reviewed tag
  no more relevant.

Vincent Guittot (6):
  sched: consolidate and cleanup access to CPU's max compute capacity
  topology: add a new arch_scale_freq_reference
  cpufreq: use the fixed and coherent frequency for scaling capacity
  cpufreq/schedutil: use a fixed reference frequency
  energy_model: use a fixed reference frequency
  cpufreq/cppc: set the frequency used for capacity computation

 Documentation/scheduler/sched-capacity.rst | 13 +++++-----
 arch/arm/include/asm/topology.h            |  1 +
 arch/arm64/include/asm/topology.h          |  1 +
 arch/riscv/include/asm/topology.h          |  1 +
 drivers/base/arch_topology.c               | 29 +++++++++++-----------
 drivers/cpufreq/cppc_cpufreq.c             | 18 ++++++++++++++
 drivers/cpufreq/cpufreq.c                  |  4 +--
 include/linux/arch_topology.h              |  7 ++++++
 include/linux/cpufreq.h                    |  9 +++++++
 include/linux/energy_model.h               | 14 ++++++++---
 kernel/sched/core.c                        |  2 +-
 kernel/sched/cpudeadline.c                 |  2 +-
 kernel/sched/cpufreq_schedutil.c           | 26 +++++++++++++++++--
 kernel/sched/deadline.c                    |  4 +--
 kernel/sched/fair.c                        | 18 ++++++--------
 kernel/sched/rt.c                          |  2 +-
 kernel/sched/sched.h                       |  6 -----
 kernel/sched/topology.c                    |  7 ++++--
 18 files changed, 113 insertions(+), 51 deletions(-)

Comments

Ingo Molnar Oct. 9, 2023, 11:01 a.m. UTC | #1

* Vincent Guittot <[e-mail]> wrote:

> Remove struct rq cpu_capacity_orig field and use arch_scale_cpu_capacity()
> instead.
> 
> Scheduler uses 3 methods to get access to the CPU's max compute capacity:
> - arch_scale_cpu_capacity(cpu) which is the default way to get CPU's capacity.
> - cpu_capacity_orig field which is periodically updated with
>   arch_scale_cpu_capacity().
> - capacity_orig_of(cpu) which encapsulates rq->cpu_capacity_orig.
> 
> There is no real need to save the value returned by arch_scale_cpu_capacity()
> in struct rq. arch_scale_cpu_capacity() returns:
> - either a per_cpu variable.
> - or a const value for systems which have only one capacity.
> 
> Remove cpu_capacity_orig and use arch_scale_cpu_capacity() everywhere.
> 
> No functional changes.
> 
> some tests of Arm64
> small SMP device (hikey): no noticeable changes
> HMP device (RB5): hackbench shows minor improvement (1-2%)
> large smp (thx2): hackbench and tbench shows minor improvement (1%)
> 
> Signed-off-by: Vincent Guittot <[e-mail]>
> Reviewed-by: Dietmar Eggemann <[e-mail]>
> 
> ---
>  Documentation/scheduler/sched-capacity.rst | 13 +++++++------
>  kernel/sched/core.c                        |  2 +-
>  kernel/sched/cpudeadline.c                 |  2 +-
>  kernel/sched/deadline.c                    |  4 ++--
>  kernel/sched/fair.c                        | 18 ++++++++----------
>  kernel/sched/rt.c                          |  2 +-
>  kernel/sched/sched.h                       |  6 ------
>  kernel/sched/topology.c                    |  7 +++++--
>  8 files changed, 25 insertions(+), 29 deletions(-)

I've applied patch #1 to tip:sched/core, thanks!

	Ingo

Lukasz Luba Oct. 18, 2023, 11:27 a.m. UTC | #2

On 10/9/23 11:36, Vincent Guittot wrote:
> This is the 1st part of consolidating how the max compute capacity is
> used in the scheduler and how we calculate the frequency for a level of
> utilization.
> 
> Fix some unconsistancy when computing frequency for an utilization. There
> can be a mismatch between energy model and schedutil.
> 
> Next step will be to make a difference between the original
> max compute capacity of a CPU and what is currently available when
> there is a capping applying forever (i.e. seconds or more).
> 
> 

I have tested the patches apart from the last CPPC because the platform
didn't have that. The EAS is working OK, so feel free to add:

Tested-by: Lukasz Luba <[e-mail]>

apart from the patch 6/6 - with the cppc changes

Regards,
Lukasz