Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime

[Dietmar Eggemann <dietmar.eggemann@arm.com>]

On 02/03/2023 09:00, Vincent Guittot wrote:
> On Wed, 1 Mar 2023 at 18:25, Qais Yousef <qyousef@layalina.io> wrote:
>>
>> On 03/01/23 11:39, Vincent Guittot wrote:
>>> On Thu, 23 Feb 2023 at 16:37, Qais Yousef <qyousef@layalina.io> wrote:
>>>>
>>>> On 02/09/23 17:16, Vincent Guittot wrote:

[...]

>>>> Just to understand why we're heading into this direction now.
>>>>
>>>> AFAIU the desired outcome to have faster rampup time (and on HMP faster up
>>>> migration) which both are tied to utilization signal.
>>>>
>>>> Wouldn't make the util response time faster help not just for rampup, but
>>>> rampdown too?
>>>>
>>>> If we improve util response time, couldn't this mean we can remove util_est or
>>>> am I missing something?
>>>
>>> not sure because you still have a ramping step whereas util_est
>>> directly gives you the final tager
>>
>> I didn't get you. tager?
> 
> target

uclamp_min boosting (ADPF's `CPU performance hints` feature) could
eclipse util_est but only if it's higher and only for those tasks
affected the feature,

[...]

>>>> I think if we can allow improving general util response time by tweaking PELT
>>>> HALFLIFE we can potentially remove util_est and potentially that magic 25%
>>>> margin too.
>>>>
>>>> Why the approach of further tweaking util_est is better?
>>>
>>> note that in this case it doesn't really tweak util_est but Dietmar
>>> has taken into account runnable_avg to increase the freq in case of
>>> contention
>>>
>>> Also IIUC Dietmar's results, the problem seems more linked to the
>>> selection of a higher freq than increasing the utilization;
>>> runnable_avg tests give similar perf results than shorter half life
>>> and better power consumption.
>>
>> Does it ramp down faster too?
> 
> I don't think so.
> 
> To be honest, I'm not convinced that modifying the half time is the
> right way to solve this. If it was only a matter of half life not
> being suitable for a system, the halk life would be set once at boot
> and people would not ask to modify it at run time.

IMHO, what people don't like about PELT halflife mods is the fact that
all sched entities and every functionality based on PELT signals would
be affected even though it might not be beneficial or even harmful for
system behaviour not covered by the specific benchmark numbers shown.

That's why we wanted to figure out what is the actual reason which
improves those Jankbench (or Speedometer resp. game FPS numbers). In
this case we would be able to boost more selectively than PELT halflife
modding can do.

Util_est_faster (1) is an approach to only boost the CPU util signal
depending on the current task's activation duration (sum of task's
running time). This time is multiplied by 2 when calculating the fake
PELT signal which is then max-compared with the existing CPU util.

And the idea to max-compare CPU util and CPU runnable (2) is to help
tasks under contention. Android testing showed that contention very
often accompanies jankframe occurrences for example.

I only applied (1) and (2) to DVFS requests in my testing.

[...]