[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jjwKr0py8H34-8ZRS8xS455YUuew8GxBex13uRq7LBPQ@mail.gmail.com>
Date: Mon, 21 Aug 2023 12:34:06 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Qais Yousef <qyousef@...alina.io>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Lukasz Luba <lukasz.luba@....com>
Subject: Re: [PATCH 0/4] Fix dvfs_headroom escaping uclamp constraints
On Sun, Aug 20, 2023 at 11:08 PM Qais Yousef <qyousef@...alina.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@...nel.org>
Powered by blists - more mailing lists