Messages in this thread | | | Date | Thu, 2 Mar 2023 20:36:38 +0100 | From | Dietmar Eggemann <> | 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@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.
[...]
| |