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

[Kajetan Puchalski]

On Thu, Sep 29, 2022 at 11:47:23AM +0200, Peter Zijlstra wrote:

[...]

> Mostly I think you've demonstrated that none of this is worth it.
> 
> > -----------------------------------------------------------------------
> > 
> > HOK ... Honour Of Kings, Video game
> > FHD ... Full High Definition
> > fps ... frame per second
> > pwr ... power consumption
> > 
> > table values are in %
> 
> Oh... that's bloody insane; that's why none of it makes sense.

Hi,

We have seen similar results to the ones provided by MTK while running
Jankbench, a UI performance benchmark.

For the following tables, the pelt numbers refer to multiplier values so
pelt_1 -> 32ms, pelt_2 -> 16ms, pelt_4 -> 8ms.

We can see the max frame durations decreasing significantly in line with
changing the pelt multiplier. Having a faster-responding pelt lets us
improve the worst-case scenario by a large margin which is why it can be
useful in some cases where that worst-case scenario is important.

Max frame duration (ms)

+------------------+----------+
| kernel          |    value  |
|------------------+----------|
| pelt_1           | 157.426  |
| pelt_2           | 111.975  |
| pelt_4           | 85.2713  |
+------------------+----------+

However, it is accompanied by a very noticeable increase in power usage.
We have seen even bigger power usage increases for different workloads.
This is why we think it makes much more sense as something that can be
changed at runtime - if set at boot time the energy consumption increase
would nullify any of the potential benefits. For limited workloads or
scenarios, the tradeoff might be worth it.

Power usage [mW]

+------------------+---------+-------------+
| kernel           |   value | perc_diff   |
|------------------+---------+-------------|
| pelt_1           |   139.9 | 0.0%        |
| pelt_2           |   146.4 | 4.62%       |
| pelt_4           |   158.5 | 13.25%      |
+------------------+---------+-------------+

At the same time we see that the average-case can improve slightly as
well in the process and the consistency either doesn't get worse or
improves a bit too.

Mean frame duration (ms)

+---------------+------------------+---------+-------------+
| variable      | kernel           |   value | perc_diff   |
|---------------+------------------+---------+-------------|
| mean_duration | pelt_1           |    14.6 | 0.0%        |
| mean_duration | pelt_2           |    13.8 | -5.43%      |
| mean_duration | pelt_4           |    14.5 | -0.58%      |
+---------------+------------------+---------+-------------+

Jank percentage

+------------+------------------+---------+-------------+
| variable   | kernel           |   value | perc_diff   |
|------------+------------------+---------+-------------|
| jank_perc  | pelt_1           |     2.1 | 0.0%        |
| jank_perc  | pelt_2           |     2.1 | 0.11%       |
| jank_perc  | pelt_4           |     2   | -3.46%      |
+------------+------------------+---------+-------------+

> How is any of that an answer to:
>
>   "They want; I want an explanation of what exact problem is fixed how ;-)"
>
> This is just random numbers showing poking the number has some effect;
> it has zero explaination of why poking the number changes the workload
> and if that is in fact the right way to go about solving that particular
> issue.

Overall, the problem being solved here is that based on our testing the
PELT half life can occasionally be too slow to keep up in scenarios
where many frames need to be rendered quickly, especially on high-refresh
rate phones and similar devices. While it's not a problem most of the
time and so it doesn't warrant changing the default or having it set at
boot time, introducing this pelt multiplier would be very useful as a
tool to be able to avoid the worst-case in limited scenarios.

----
Kajetan