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

[Thara Gopinath <thara.gopinath@linaro.org>]

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