mbox series

[0/4] Fix dvfs_headroom escaping uclamp constraints

Message ID 20230820210640.585311-1-qyousef@layalina.io (mailing list archive)
Headers show
Series Fix dvfs_headroom escaping uclamp constraints | expand

Message

Qais Yousef Aug. 20, 2023, 9:06 p.m. UTC
DVFS headroom, or map_util_perf(), is applied after uclamp restrictions are
applied in effective_cpu_util(). This will lead to two problems for uclamp:

	1. If util < uclamp_min, we'll run faster than uclamp_min. For example
	   util = 50, uclamp_min = 100. map_util_perf() = 125 instead of 100.

	2. If util > uclamp_max, we'll run faster than uclamp_max. For example
	   util = 900, uclamp_max = 800, map_util_perf() = 1000.

First patch rename the function to apply_dvfs_headroom() to reflect what it
really does. It is not really mapping util, but provides some headroom for the
util to grow. Provide a documentation for the function too.

Second patch is the actual fix.

Third patch moves apply_dvfs_headroom() to sched.h as there are no longer
users outside the scheduler.

Fourth patch is an RFC to redefine what the headroom means for RT, DL and IRQ
pressures.

Thanks!

--
Qais Yousef

Qais Yousef (4):
  sched: cpufreq: Rename map_util_perf to apply_dvfs_headroom
  sched: cpufreq: Fix apply_dvfs_headroom() escaping uclamp constraints
  sched: cpufreq: Move apply_dvfs_headroom() to sched.h
  sched: cpufreq: Apply DVFS headroom to CFS only

 include/linux/energy_model.h     |  1 -
 include/linux/sched/cpufreq.h    |  5 -----
 kernel/sched/core.c              |  7 +++++--
 kernel/sched/cpufreq_schedutil.c |  5 ++---
 kernel/sched/sched.h             | 24 ++++++++++++++++++++++++
 5 files changed, 31 insertions(+), 11 deletions(-)

Comments

Rafael J. Wysocki Aug. 21, 2023, 10:34 a.m. UTC | #1
On Sun, Aug 20, 2023 at 11:08 PM Qais Yousef <qyousef@layalina.io> wrote:
>
> DVFS headroom, or map_util_perf(), is applied after uclamp restrictions are
> applied in effective_cpu_util(). This will lead to two problems for uclamp:
>
>         1. If util < uclamp_min, we'll run faster than uclamp_min. For example
>            util = 50, uclamp_min = 100. map_util_perf() = 125 instead of 100.
>
>         2. If util > uclamp_max, we'll run faster than uclamp_max. For example
>            util = 900, uclamp_max = 800, map_util_perf() = 1000.
>
> First patch rename the function to apply_dvfs_headroom() to reflect what it
> really does. It is not really mapping util, but provides some headroom for the
> util to grow. Provide a documentation for the function too.
>
> Second patch is the actual fix.
>
> Third patch moves apply_dvfs_headroom() to sched.h as there are no longer
> users outside the scheduler.
>
> Fourth patch is an RFC to redefine what the headroom means for RT, DL and IRQ
> pressures.
>
> Thanks!

For the first 3 patches in the series

Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Qais Yousef Aug. 26, 2023, 7:17 p.m. UTC | #2
On 08/21/23 12:34, Rafael J. Wysocki wrote:
> On Sun, Aug 20, 2023 at 11:08 PM Qais Yousef <qyousef@layalina.io> wrote:
> >
> > DVFS headroom, or map_util_perf(), is applied after uclamp restrictions are
> > applied in effective_cpu_util(). This will lead to two problems for uclamp:
> >
> >         1. If util < uclamp_min, we'll run faster than uclamp_min. For example
> >            util = 50, uclamp_min = 100. map_util_perf() = 125 instead of 100.
> >
> >         2. If util > uclamp_max, we'll run faster than uclamp_max. For example
> >            util = 900, uclamp_max = 800, map_util_perf() = 1000.
> >
> > First patch rename the function to apply_dvfs_headroom() to reflect what it
> > really does. It is not really mapping util, but provides some headroom for the
> > util to grow. Provide a documentation for the function too.
> >
> > Second patch is the actual fix.
> >
> > Third patch moves apply_dvfs_headroom() to sched.h as there are no longer
> > users outside the scheduler.
> >
> > Fourth patch is an RFC to redefine what the headroom means for RT, DL and IRQ
> > pressures.
> >
> > Thanks!
> 
> For the first 3 patches in the series
> 
> Acked-by: Rafael J. Wysocki <rafael@kernel.org>

Thanks for having a look!


Cheers

--
Qais Yousef