linux-kernel - Re: [RFC] Documentation/scheduler/schedutil.txt

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:   Mon, 23 Nov 2020 19:39:08 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Patrick Bellasi <patrick.bellasi@...bug.net>,
        "Cc: Len Brown" <lenb@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Ionela Voinescu <ionela.voinescu@....com>,
        Quentin Perret <qperret@...gle.com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [RFC] Documentation/scheduler/schedutil.txt

On 23/11/2020 14:42, Vincent Guittot wrote:
> On Mon, 23 Nov 2020 at 12:27, Dietmar Eggemann <dietmar.eggemann@....com> wrote:
>>
>> On 23/11/2020 11:05, Vincent Guittot wrote:
>>> On Mon, 23 Nov 2020 at 10:30, Dietmar Eggemann <dietmar.eggemann@....com> wrote:
>>>>
>>>> On 20/11/2020 09:56, Peter Zijlstra wrote:
>>>>> On Fri, Nov 20, 2020 at 08:55:27AM +0100, Peter Zijlstra wrote:

[...]

>> I thought the question was whether 'runnable_avg = 1.5 x
>> SCHED_CAPACITY_SCALE' is a good threshold to decide to drive frequency
>> by runnable_avg or util_avg.
> 
> we can't use SCHED_CAPACITY_SCALE and must use cpu's capacity

To get some idle time on the LITTLE CPU I extended the time in which
task3 and then task2-3 run on CPU5 to 128ms.

The moment CPU4 has some idle time for the first time after the first
migration (~207ms), the runnable_avg drops from 1323 (task0: 316,
task1: 1020) to 1.
I can't see the dependency to the CPU capacity here.
Util_avg is also larger than the CPU capacity.

The steep fall from runnable=1323 to 1 is due to lost_idle_time update.

...
migration/4-29 [004] 60.000034: sched_migrate_task: comm=task3-3 pid=1690 prio=101 orig_cpu=4 dest_cpu=5
migration/4-29 [004] 60.000046: sched_pelt_cfs:     cpu=4 path=/ load=163618 runnable=2296 util=748
...
migration/4-29 [004] 60.142088: sched_migrate_task: comm=task2-2 pid=1689 prio=101 orig_cpu=4 dest_cpu=5
migration/4-29 [004] 60.142100: sched_pelt_cfs:     cpu=4 path=/ load=93358 runnable=1325 util=628
...
task0-0-1687   [004] 60.201385: sched_pelt_se:      cpu=4 path=(null) comm=task0-0 pid=1687 load=22317 runnable=316 util=316
task0-0-1687   [004] 60.201387: sched_pelt_cfs:     cpu=4 path=/ load=93978 runnable=1336 util=788
...
task1-1-1688   [004] 60.207225: sched_pelt_se:      cpu=4 path=(null) comm=task1-1 pid=1688 load=71610 runnable=1020 util=497
task1-1-1688   [004] 60.207227: sched_pelt_cfs:     cpu=4 path=/ load=93017 runnable=1323 util=800
 <idle>-0      [004] 60.207254: cpu_idle:           state=0 cpu_id=4
...
 <idle>-0      [004] 60.209397: sched_pelt_cfs:     cpu=4 path=/ load=80 runnable=1 util=0
...