[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c56855a7-14fd-4737-fc8b-8ea21487c5f6@arm.com>
Date: Wed, 18 Jan 2023 17:48:32 +0000
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Chen Yu <yu.c.chen@...el.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Tim Chen <tim.c.chen@...el.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Juri Lelli <juri.lelli@...hat.com>,
Rik van Riel <riel@...riel.com>,
Aaron Lu <aaron.lu@...el.com>,
Abel Wu <wuyun.abel@...edance.com>,
K Prateek Nayak <kprateek.nayak@....com>,
Yicong Yang <yangyicong@...ilicon.com>,
"Gautham R . Shenoy" <gautham.shenoy@....com>,
Ingo Molnar <mingo@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Valentin Schneider <vschneid@...hat.com>,
Hillf Danton <hdanton@...a.com>,
Honglei Wang <wanghonglei@...ichuxing.com>,
Len Brown <len.brown@...el.com>,
Chen Yu <yu.chen.surf@...il.com>,
Tianchen Ding <dtcccc@...ux.alibaba.com>,
Joel Fernandes <joel@...lfernandes.org>,
Josh Don <joshdon@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v4 1/2] sched/fair: Introduce short duration task
check
On 16/01/2023 10:33, Peter Zijlstra wrote:
> On Thu, Jan 05, 2023 at 12:33:16PM +0100, Dietmar Eggemann wrote:
>> On 16/12/2022 07:11, Chen Yu wrote:
[...]
> You were thinking of the dynamic PELT window size thread? (which is what
> I had to think of when I looked at this).
Yes, indeed.
> I think we can still do that with this prev_sum_exec_runtime_vol (can't
> say I love the name though). At any point (assuming we update
> sum_exec_runtime) sum_exec_runtime - prev_sum_exec_runtime_vol is the
> duration of the current activation.
I ran Jankbench with your UTIL_EST_FASTER patch and:
runtime = curr->se.sum_exec_runtime -
curr->se.prev_sum_exec_runtime_vol
plus:
runtime >>= 10
before doing:
util_est_fast = faster_est_approx(runtime * 2)
^^^ (boost)
on a Pixel6 and the results look promising:
Max frame duration (ms)
+-------------------+-----------+------------+
| wa_path | iteration | value |
+-------------------+-----------+------------+
| base | 10 | 147.571352 |
| pelt-hl-m2 | 10 | 119.416351 |
| pelt-hl-m4 | 10 | 96.473412 |
| util_est_faster | 10 | 84.834999 |
+-------------------+-----------+------------+
Mean frame duration (average case)
+---------------+-------------------+-------+-----------+
| variable | kernel | value | perc_diff |
+---------------+-------------------+-------+-----------+
| mean_duration | base | 14.7 | 0.0% |
| mean_duration | pelt-hl-m2 | 13.6 | -7.5% |
| mean_duration | pelt-hl-m4 | 13.0 | -11.68% |
| mean_duration | util_est_faster | 12.6 | -14.01% |
+---------------+-------------------+-------+-----------+
Jank percentage
+-----------+-------------------+-------+-----------+
| variable | kernel | value | perc_diff |
+-----------+-------------------+-------+-----------+
| jank_perc | base | 1.8 | 0.0% |
| jank_perc | pelt-hl-m2 | 1.8 | -4.91% |
| jank_perc | pelt-hl-m4 | 1.2 | -36.61% |
| jank_perc | util_est_faster | 0.8 | -57.8% |
+-----------+-------------------+-------+-----------+
Power usage [mW]
+--------------+-------------------+-------+-----------+
| chan_name | kernel | value | perc_diff |
+--------------+-------------------+-------+-----------+
| total_power | base | 144.4 | 0.0% |
| total_power | pelt-hl-m2 | 141.6 | -1.97% |
| total_power | pelt-hl-m4 | 163.2 | 12.99% |
| total_power | util_est_faster | 150.9 | 4.45% |
+--------------+-------------------+-------+-----------+
At first glance it looks promising! Have to do more testing to
understand the behaviour fully.
Powered by blists - more mailing lists