linux-kernel - Re: [PATCH v4 2/2] sched/fair: update scale invariance of PELT

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] [day] [month] [year] [list]

Message-ID: <395c9d6d-e717-69a5-f54c-5b3c3845f0ef@arm.com>
Date:   Thu, 25 Oct 2018 13:08:46 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Morten Rasmussen <Morten.Rasmussen@....com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Paul Turner <pjt@...gle.com>, Ben Segall <bsegall@...gle.com>,
        Thara Gopinath <thara.gopinath@...aro.org>
Subject: Re: [PATCH v4 2/2] sched/fair: update scale invariance of PELT

On 10/25/18 12:43 PM, Vincent Guittot wrote:
> On Thu, 25 Oct 2018 at 12:36, Dietmar Eggemann <dietmar.eggemann@....com> wrote:

[...]

>> I have a couple of questions related to the tests you ran.
>>
>>> On a hikey (octo ARM platform).
>>> Performance cpufreq governor and only shallowest c-state to remove variance
>>> generated by those power features so we only track the impact of pelt algo.
>>
>> So you disabled c-state 'cpu-sleep' and 'cluster-sleep'?
> 
> yes
> 
>>
>> I get 'hisi_thermal f7030700.tsensor: THERMAL ALARM: 66385 > 65000' on
>> my hikey620. Did you change the thermal configuration? Not sure if there
>> are any actions attached to this warning though.
> 
> I have a fan to ensure that no thermal mitigation will bias the measurement.

Great, with a fan they disappear here as well.

>>> each test runs 16 times
>>>
>>> ./perf bench sched pipe
>>> (higher is better)
>>> kernel        tip/sched/core     + patch
>>>           ops/seconds        ops/seconds         diff
>>> cgroup
>>> root    59648(+/- 0.13%)   59785(+/- 0.24%)    +0.23%
>>> level1  55570(+/- 0.21%)   56003(+/- 0.24%)    +0.78%
>>> level2  52100(+/- 0.20%)   52788(+/- 0.22%)    +1.32%
>>>
>>> hackbench -l 1000
>>
>> Shouldn't this be '-l 100'?
> 
> I have re checked and it's -l 1000

Strange, when I run hackbench on this board (performance governor) I get 
values like:

root@...0:/# hackbench -l 100
Running in process mode with 10 groups using 40 file descriptors each 
(== 400 tasks)
Each sender will pass 100 messages of 100 bytes
Time: 4.023

root@...0:/# hackbench -l 1000
Running in process mode with 10 groups using 40 file descriptors each 
(== 400 tasks)
Each sender will pass 1000 messages of 100 bytes
Time: 37.883

Since you have values in the range of 4-6 secs in your hackbench table? 
Maybe different hackbench versions?

>>> (lower is better)
>>> kernel        tip/sched/core     + patch
>>>           duration(sec)      duration(sec)        diff
>>> cgroup
>>> root    4.472(+/- 1.86%)   4.346(+/- 2.74%)     -2.80%
>>> level1  5.039(+/- 11.05%)  4.662(+/- 7.57%)     -7.47%
>>> level2  5.195(+/- 10.66%)  4.877(+/- 8.90%)     -6.12%
>>>
>>> The responsivness of PELT is improved when CPU is not running at max
>>> capacity with this new algorithm. I have put below some examples of
>>> duration to reach some typical load values according to the capacity of the
>>> CPU with current implementation and with this patch.
>>>
>>> Util (%)     max capacity  half capacity(mainline)  half capacity(w/ patch)
>>> 972 (95%)    138ms         not reachable            276ms
>>> 486 (47.5%)  30ms          138ms                     60ms
>>> 256 (25%)    13ms           32ms                     26ms
>>
>> Could you describe these testcases in more detail?
> 
> You don't need to run test case. These numbers are computed based on
> geometric series and half period value

Ah, ok, maybe you can mention this explicitly.

[...]

>> What's the initial utilization value of t1? I assume t1 starts with
>> utilization=512 (post_init_entity_util_avg()).

OK, then it's starts at 0.

>>> On my hikey (octo ARM platform) with schedutil governor, the time to reach
>>> max OPP when starting from a null utilization, decreases from 223ms with
>>> current scale invariance down to 121ms with the new algorithm. For this
>>> test, I have enable arch_scale_freq for arm64.
>>
>> Isn't the arch-specific arch_scale_freq_capacity() enabled by default on
>> arm64 with cpufreq support?
> 
> Yes. that's a remain of previous version when arch_scale_freq was not yet merged

OK.

[...]