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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c81955c0-5f2e-e0e9-1a9a-5d005066df06@arm.com>
Date:   Thu, 2 Mar 2023 20:36:38 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Qais Yousef <qyousef@...alina.io>,
        Kajetan Puchalski <kajetan.puchalski@....com>,
        Jian-Min Liu <jian-min.liu@...iatek.com>,
        Ingo Molnar <mingo@...nel.org>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Vincent Donnefort <vdonnefort@...gle.com>,
        Quentin Perret <qperret@...gle.com>,
        Patrick Bellasi <patrick.bellasi@...bug.net>,
        Abhijeet Dharmapurikar <adharmap@...cinc.com>,
        Qais Yousef <qais.yousef@....com>,
        linux-kernel@...r.kernel.org,
        Jonathan JMChen <jonathan.jmchen@...iatek.com>
Subject: Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime

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@....com> wrote:
>>>
>>> On 09/02/2023 17:16, Vincent Guittot wrote:
>>>> On Tue, 7 Feb 2023 at 11:29, Dietmar Eggemann <dietmar.eggemann@....com> 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.

[...]