On 04/17/2019 01:55 AM, Ingo Molnar wrote: > > * Ingo Molnar <mi...@kernel.org> wrote: > >> * Thara Gopinath <thara.gopin...@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
