Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v4 2/2] sched/fair: update scale invariance of PELT
To:     Vincent Guittot <vincent.guittot@linaro.org>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Morten Rasmussen <Morten.Rasmussen@arm.com>,
        Patrick Bellasi <patrick.bellasi@arm.com>,
        Paul Turner <pjt@google.com>, Ben Segall <bsegall@google.com>,
        Thara Gopinath <thara.gopinath@linaro.org>
References: <1539965871-22410-1-git-send-email-vincent.guittot@linaro.org>
 <1539965871-22410-3-git-send-email-vincent.guittot@linaro.org>
 <43b126ab-403b-3fb3-5951-45a107e4a14b@arm.com>
 <CAKfTPtCypUSMu8JG_tdqwK4EnAjCbunDXzJvsPwBjqm+D5iG9g@mail.gmail.com>
From:   Dietmar Eggemann <dietmar.eggemann@arm.com>
Message-ID: <395c9d6d-e717-69a5-f54c-5b3c3845f0ef@arm.com>
Date:   Thu, 25 Oct 2018 13:08:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CAKfTPtCypUSMu8JG_tdqwK4EnAjCbunDXzJvsPwBjqm+D5iG9g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 10/25/18 12:43 PM, Vincent Guittot wrote:
> On Thu, 25 Oct 2018 at 12:36, Dietmar Eggemann <dietmar.eggemann@arm.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@h620:/# 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@h620:/# 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.

[...]