lkml.org 
[lkml]   [2019]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH V2 0/3] Introduce Thermal Pressure
From
Date
On 04/17/2019 01:55 AM, Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
>> * Thara Gopinath <thara.gopinath@linaro.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

\
 
 \ /
  Last update: 2019-04-17 19:29    [W:0.116 / U:2.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site