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

From: Dietmar Eggemann
Date: Thu Mar 02 2023 - 14:36:55 EST


On 22/02/2023 21:13, Dietmar Eggemann wrote:
> On 20/02/2023 14:54, Vincent Guittot wrote:
>> On Fri, 17 Feb 2023 at 14:54, Dietmar Eggemann <dietmar.eggemann@xxxxxxx> wrote:
>>>
>>> On 09/02/2023 17:16, Vincent Guittot wrote:
>>>> On Tue, 7 Feb 2023 at 11:29, Dietmar Eggemann <dietmar.eggemann@xxxxxxx> wrote:
>>>>>
>>>>> On 09/11/2022 16:49, Peter Zijlstra wrote:
>>>>>> On Tue, Nov 08, 2022 at 07:48:43PM +0000, Qais Yousef wrote:
>>>>>>> On 11/07/22 14:41, Peter Zijlstra wrote:
>>>>>>>> On Thu, Sep 29, 2022 at 03:41:47PM +0100, Kajetan Puchalski wrote:
>
> [...]
>
>>>> Graphics Pipeline short task, hasn't uclamp_min been designed for and
>>>> a better solution ?
>>>
>>> Yes, it has. I'm not sure how feasible this is to do for all tasks
>>> involved. I'm thinking about the Binder threads here for instance.
>>
>> Yes, that can probably not help for all threads but some system
>> threads like surfaceflinger and graphic composer should probably
>> benefit from min uclamp
>
> Yes, and it looks like that the Android version I'm using
> SQ1D.220205.004 (Feb '22) (automatic system updates turned off) is
> already using uclamp_min != 0 for tasks like UI thread. It's not one
> particular value but different values from [0 .. 512] over the runtime
> of a Jankbench iteration. I have to have a closer look.

I did more Jankbench and Speedometer testing especially to understand
the influence of the already used uclamp_min boosting (Android Dynamic
Performance Framework (ADPF) `CPU performance hints` feature:
https://developer.android.com/games/optimize/adpf#cpu-hints) for some
App tasks.

The following notebooks show which of the App tasks are uclamp_min
boosted (their diagram title carries an additional 'uclamp_min_boost'
tag and how uclamp_min boost relates to the other boost values:
This is probably not a fixed mapping and could change between test runs.
I assume that Android will issue performance hints in form of uclamp_min
boosting when it detects certain scenarios like a specific jankframe
threshold or something similar.

https://nbviewer.org/github/deggeman/lisa/blob/ipynbs/ipynb/scratchpad/jankbench_uclamp_min_boost.ipynb

https://nbviewer.org/github/deggeman/lisa/blob/ipynbs/ipynb/scratchpad/speedometer_uclamp_min_boost.ipynb

`base` has changed compared to `base-a30b17f016b0`. It now also
contains: e5ed0550c04c - sched/fair: unlink misfit task from cpu
overutilized (2023-02-11 Vincent Guittot)

Former `max_util_scaled_util_est_faster_rbl_freq` has been renamed to
`cpu_rbl_freq`.

Jankbench:

Max_frame_duration:
+-----------------------------+------------+
| kernel | value |
+-----------------------------+------------+
| base | 156.299159 |
| base_wo_uclamp | 171.063764 | uclamp disabled*
| pelt-hl-m2 | 126.190232 |
| pelt-hl-m4 | 100.865171 |
| scaled_util_est_faster_freq | 126.074194 |
| cpu_rbl_freq | 153.123089 |
+-----------------------------+------------+

* We still let Android set the uclamp_min values.
Just the uclamp setter are bypassed now.

Mean_frame_duration:
+-----------------------------+-------+-----------+
| kernel | value | perc_diff |
+-----------------------------+-------+-----------+
| base | 15.5 | 0.0% |
| base_wo_uclamp | 16.6 | 7.76% |
| pelt-hl-m2 | 14.9 | -3.27% |
| pelt-hl-m4 | 13.6 | -12.16% |
| scaled_util_est_faster_freq | 14.7 | -4.88% |
| cpu_rbl_freq | 12.2 | -20.84% |
+-----------------------------+-------+-----------+

Jank percentage (Jank deadline 16ms):
+-----------------------------+-------+-----------+
| kernel | value | perc_diff |
+-----------------------------+-------+-----------+
| base | 2.6 | 0.0% |
| base_wo_uclamp | 3.0 | 17.47% |
| pelt-hl-m2 | 2.0 | -23.33% |
| pelt-hl-m4 | 1.3 | -48.55% |
| scaled_util_est_faster_freq | 1.7 | -32.21% |
| cpu_rbl_freq | 0.7 | -71.36% |
+-----------------------------+-------+-----------+

Power usage [mW] (total - all CPUs):
+-----------------------------+-------+-----------+
| kernel | value | perc_diff |
+-----------------------------+-------+-----------+
| base | 141.1 | 0.0% |
| base_wo_uclamp | 116.6 | -17.4% |
| pelt-hl-m2 | 138.7 | -1.7% |
| pelt-hl-m4 | 156.5 | 10.87% |
| scaled_util_est_faster_freq | 147.6 | 4.57% |
| cpu_rbl_freq | 135.0 | -4.33% |
+-----------------------------+-------+-----------+

Speedometer:

Score:
+-----------------------------+-------+-----------+
| kernel | value | perc_diff |
+-----------------------------+-------+-----------+
| base | 108.4 | 0.0% |
| base_wo_uclamp | 95.2 | -12.17% |
| pelt-hl-m2 | 112.9 | 4.13% |
| scaled_util_est_faster_freq | 114.7 | 5.77% |
| cpu_rbl_freq | 127.7 | 17.75% |
+-----------------------------+-------+-----------+

Power usage [mW] (total - all CPUs):
+-----------------------------+--------+-----------+
| kernel | value | perc_diff |
+-----------------------------+--------+-----------+
| base | 2268.4 | 0.0% |
| base_wo_uclamp | 1789.5 | -21.11% |
| pelt-hl-m2 | 2386.5 | 5.21% |
| scaled_util_est_faster_freq | 2292.3 | 1.05% |
| cpu_rbl_freq | 2198.3 | -3.09% |
+-----------------------------+--------+-----------+

The explanation I have is that the `CPU performance hints` feature
tries to recreate the information about contention for a specific set of
tasks. Since there is also contention in which only non uclamp_min
boosted tasks are runnable, mechanisms like `util_est_faster` or
`cpu_runnable boosting` can help on top of what's already provided with
uclamp_min boosting from userspace.

[...]