From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Qais Yousef <qyousef@layalina.io>,
Kajetan Puchalski <kajetan.puchalski@arm.com>,
Jian-Min Liu <jian-min.liu@mediatek.com>,
Ingo Molnar <mingo@kernel.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Vincent Donnefort <vdonnefort@google.com>,
Quentin Perret <qperret@google.com>,
Patrick Bellasi <patrick.bellasi@matbug.net>,
Abhijeet Dharmapurikar <adharmap@quicinc.com>,
Qais Yousef <qais.yousef@arm.com>,
linux-kernel@vger.kernel.org,
Jonathan JMChen <jonathan.jmchen@mediatek.com>
Subject: Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime
Date: Thu, 2 Mar 2023 20:36:38 +0100 [thread overview]
Message-ID: <c81955c0-5f2e-e0e9-1a9a-5d005066df06@arm.com> (raw)
In-Reply-To: <36bfd828-5af7-3bcb-d642-3361820c6071@arm.com>
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@arm.com> wrote:
>>>
>>> On 09/02/2023 17:16, Vincent Guittot wrote:
>>>> On Tue, 7 Feb 2023 at 11:29, Dietmar Eggemann <dietmar.eggemann@arm.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.
[...]
next prev parent reply other threads:[~2023-03-02 19:36 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 5:54 [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime Dietmar Eggemann
2022-08-29 5:54 ` [RFC PATCH 1/1] sched/pelt: Introduce PELT multiplier Dietmar Eggemann
2022-08-29 8:08 ` Peter Zijlstra
2022-08-29 10:02 ` Peter Zijlstra
2022-08-29 10:13 ` Vincent Guittot
2022-08-29 14:23 ` Quentin Perret
2022-08-29 14:34 ` Peter Zijlstra
2022-08-29 15:31 ` Quentin Perret
2022-08-29 15:48 ` Quentin Perret
2022-09-02 7:53 ` Dietmar Eggemann
2022-09-02 8:45 ` Peter Zijlstra
2022-09-06 5:49 ` Vincent Guittot
2022-09-08 6:50 ` Dietmar Eggemann
2022-09-02 7:53 ` Dietmar Eggemann
2022-09-02 8:45 ` Peter Zijlstra
2022-09-20 14:07 ` [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime Jian-Min Liu
2022-09-28 17:09 ` Dietmar Eggemann
2022-09-29 9:47 ` Peter Zijlstra
2022-09-29 11:07 ` Dietmar Eggemann
2022-09-29 11:10 ` Kajetan Puchalski
2022-09-29 11:21 ` Peter Zijlstra
2022-09-29 14:41 ` Kajetan Puchalski
2022-10-03 22:57 ` Wei Wang
2022-10-04 9:33 ` Dietmar Eggemann
2022-10-05 16:57 ` Wei Wang
2022-11-07 13:41 ` Peter Zijlstra
2022-11-08 19:48 ` Qais Yousef
2022-11-09 15:49 ` Peter Zijlstra
2022-11-10 13:25 ` Qais Yousef
2023-02-07 10:29 ` Dietmar Eggemann
2023-02-09 16:16 ` Vincent Guittot
2023-02-17 13:54 ` Dietmar Eggemann
2023-02-20 13:54 ` Vincent Guittot
2023-02-21 9:29 ` Vincent Guittot
2023-02-22 20:28 ` Dietmar Eggemann
2023-03-01 10:24 ` Vincent Guittot
2023-02-22 20:13 ` Dietmar Eggemann
2023-03-02 19:36 ` Dietmar Eggemann [this message]
2023-02-20 10:13 ` Peter Zijlstra
2023-02-20 13:39 ` Vincent Guittot
2023-02-23 15:37 ` Qais Yousef
2023-03-01 10:39 ` Vincent Guittot
2023-03-01 17:24 ` Qais Yousef
2023-03-02 8:00 ` Vincent Guittot
2023-03-02 19:39 ` Dietmar Eggemann
2023-03-06 19:11 ` Qais Yousef
2023-03-07 13:22 ` Vincent Guittot
2023-03-11 16:55 ` Qais Yousef
2023-03-23 16:29 ` Dietmar Eggemann
2023-04-03 14:45 ` Qais Yousef
2023-04-06 15:58 ` Dietmar Eggemann
2023-04-11 17:51 ` Qais Yousef
2022-11-09 15:18 ` Lukasz Luba
2022-11-10 11:16 ` Dietmar Eggemann
2022-11-10 13:05 ` Peter Zijlstra
2022-11-10 14:59 ` Dietmar Eggemann
2022-11-10 17:51 ` Peter Zijlstra
2022-11-30 18:14 ` Dietmar Eggemann
2022-12-01 13:37 ` Kajetan Puchalski
2022-11-10 12:45 ` Kajetan Puchalski
2022-11-07 9:41 ` Jian-Min Liu (劉建旻)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c81955c0-5f2e-e0e9-1a9a-5d005066df06@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=adharmap@quicinc.com \
--cc=jian-min.liu@mediatek.com \
--cc=jonathan.jmchen@mediatek.com \
--cc=kajetan.puchalski@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=qyousef@layalina.io \
--cc=vdonnefort@google.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).