linux-kernel - Re: [RFC PATCH v4 1/2] sched/fair: Introduce short duration task check

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]

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.