lkml.org 
[lkml]   [2019]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

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