linux-kernel - Re: [PATCH V2 0/3] Introduce Thermal Pressure

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]

Message-ID: <5CB76233.9080508@linaro.org>
Date:   Wed, 17 Apr 2019 13:28:19 -0400
From:   Thara Gopinath <thara.gopinath@...aro.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     mingo@...hat.com, peterz@...radead.org, rui.zhang@...el.com,
        linux-kernel@...r.kernel.org, amit.kachhap@...il.com,
        viresh.kumar@...aro.org, javi.merino@...nel.org,
        edubezval@...il.com, daniel.lezcano@...aro.org,
        vincent.guittot@...aro.org, nicolas.dechesne@...aro.org,
        bjorn.andersson@...aro.org, dietmar.eggemann@....com
Subject: Re: [PATCH V2 0/3] Introduce Thermal Pressure

On 04/17/2019 01:55 AM, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@...nel.org> wrote:
> 
>> * Thara Gopinath <thara.gopinath@...aro.org> wrote:
>>
>>> The test results below shows 3-5% improvement in performance when
>>> using the third solution compared to the default system today where
>>> scheduler is unware of cpu capacity limitations due to thermal events.
>>
>> The numbers look very promising!
>>
>> I've rearranged the results to make the performance properties of the 
>> various approaches and parameters easier to see:
>>
>>                                          (seconds, lower is better)
>>
>> 			                 Hackbench   Aobench   Dhrystone
>>                                          =========   =======   =========
>> Vanilla kernel (No Thermal Pressure)         10.21    141.58        1.14
>> Instantaneous thermal pressure               10.16    141.63        1.15
>> Thermal Pressure Averaging:
>>       - PELT fmwk                             9.88    134.48        1.19
>>       - non-PELT Algo. Decay : 500 ms         9.94    133.62        1.09
>>       - non-PELT Algo. Decay : 250 ms         7.52    137.22        1.012
>>       - non-PELT Algo. Decay : 125 ms         9.87    137.55        1.12
> 
> So what I forgot to say is that IMO your results show robust improvements 
> over the vanilla kernel of around 5%, with a relatively straightforward 
> thermal pressure metric. So I suspect we could do something like this, if 
> there was a bit more measurements done to get the best decay period 
> established - the 125-250-500 msecs results seem a bit coarse and not 
> entirely unambiguous.

To give you the background, I started with decay period of 500 ms. No
other reason except the previous version of rt-pressure that existed in
the scheduler employed a 500 ms decay period. Then the idea was to
decrease the decay period by half and see what happens and so on. But I
agree, that it is a bit coarse. I will probably get around to
implementing some of your suggestions to capture more granular results
in the next few weeks.
> 
> In terms of stddev: the perf stat --pre hook could be used to add a dummy 
> benchmark run, to heat up the test system, to get more reliable, less 
> noisy numbers?
> 
> BTW., that big improvement in hackbench results to 7.52 at 250 msecs, is 
> that real, or a fluke perhaps?
For me, it is an anomaly. Having said that, I did rerun the tests with
this configuration at least twice(if not more) and the results were
similar. It is an anomaly because I have no explanation as to why there
is so much improvement at the 250 ms decay period.

> 
> Thanks,
> 
> 	Ingo
> 


-- 
Regards
Thara