Messages in this thread | | | Date | Wed, 17 Apr 2019 20:29:32 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH V2 0/3] Introduce Thermal Pressure |
| |
* Thara Gopinath <thara.gopinath@linaro.org> wrote:
> > On 04/17/2019 01:36 AM, Ingo Molnar 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! > > Hello Ingo, > Thank you for the review. > > > > 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 > > > > > > Firstly, a couple of questions about the numbers: > > > > 1) > > > > Is the 1.012 result for "non-PELT 250 msecs Dhrystone" really 1.012? > > You reported it as: > > > > non-PELT Algo. Decay : 250 ms 1.012 7.02% > > It is indeed 1.012. So, I ran the "non-PELT Algo 250 ms" benchmarks > multiple time because of the anomalies noticed. 1.012 is a formatting > error on my part when I copy pasted the results into a google sheet I am > maintaining to capture the test results. Sorry about the confusion.
That's actually pretty good, because it suggests a 35% and 15% improvement over the vanilla kernel - which is very good for such CPU-bound workloads.
Not that 5% is bad in itself - but 15% is better ;-)
> Regarding the decay period, I agree that more testing can be done. I > like your suggestions below and I am going to try implementing them > sometime next week. Once I have some solid results, I will send them > out.
Thanks!
> My concern regarding getting hung up too much on decay period is that I > think it could vary from SoC to SoC depending on the type and number of > cores and thermal characteristics. So I was thinking eventually the > decay period should be configurable via a config option or by any other > means. Testing on different systems will definitely help and maybe I am > wrong and there is no much variation between systems.
Absolutely, so I'd not be against keeping it a SCHED_DEBUG tunable or so, until there's a better understanding of how the physical properties of the SoC map to an ideal decay period.
Assuming PeterZ & Rafael & Quentin doesn't hate the whole thermal load tracking approach. I suppose there's some connection of this to Energy Aware Scheduling? Or not ...
Thanks,
Ingo
| |