From: Thara Gopinath <thara.gopinath@linaro.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, ionela.voinescu@arm.com,
vincent.guittot@linaro.org, rui.zhang@intel.com,
qperret@google.com, daniel.lezcano@linaro.org,
viresh.kumar@linaro.org, linux-kernel@vger.kernel.org,
amit.kachhap@gmail.com, javi.merino@kernel.org,
amit.kucheria@verdurent.com
Subject: Re: [Patch v6 0/7] Introduce Thermal Pressure
Date: Sat, 11 Jan 2020 10:04:36 -0500 [thread overview]
Message-ID: <5E19E404.1020601@linaro.org> (raw)
In-Reply-To: <20191216145624.GU2844@hirez.programming.kicks-ass.net>
On 12/16/2019 09:56 AM, Peter Zijlstra wrote:
> On Wed, Dec 11, 2019 at 11:11:41PM -0500, Thara Gopinath wrote:
>> Test Results
>>
>> Hackbench: 1 group , 30000 loops, 10 runs
>> Result SD
>> (Secs) (% of mean)
>> No Thermal Pressure 14.03 2.69%
>> Thermal Pressure PELT Algo. Decay : 32 ms 13.29 0.56%
>> Thermal Pressure PELT Algo. Decay : 64 ms 12.57 1.56%
>> Thermal Pressure PELT Algo. Decay : 128 ms 12.71 1.04%
>> Thermal Pressure PELT Algo. Decay : 256 ms 12.29 1.42%
>> Thermal Pressure PELT Algo. Decay : 512 ms 12.42 1.15%
>>
>> Dhrystone Run Time : 20 threads, 3000 MLOOPS
>> Result SD
>> (Secs) (% of mean)
>> No Thermal Pressure 9.452 4.49%
>> Thermal Pressure PELT Algo. Decay : 32 ms 8.793 5.30%
>> Thermal Pressure PELT Algo. Decay : 64 ms 8.981 5.29%
>> Thermal Pressure PELT Algo. Decay : 128 ms 8.647 6.62%
>> Thermal Pressure PELT Algo. Decay : 256 ms 8.774 6.45%
>> Thermal Pressure PELT Algo. Decay : 512 ms 8.603 5.41%
>
> What is the conclusion, if any from these results? Clearly thermal
> pressuse seems to help, but what window? ISTR we default to 32ms, which
> is a wash for drystone, but sub-optimal for hackbench.
Hi Peter,
Thanks for the reviews. IMHO, the conclusion is that thermal pressure is
beneficial but the decay period to be used depends on the architecture
and/or use-cases. Sticking to 32ms should give some improvement but it
can be tuned depending on the system.
>
>
> Anyway, the patches look more or less acceptible, just a bunch of nits,
> the biggest being the fact that even if an architecture does not support
> this there is still the code and runtime overhead.
I am fixing this and sending out a v7.
>
--
Warm Regards
Thara
prev parent reply other threads:[~2020-01-11 15:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 4:11 [Patch v6 0/7] Introduce Thermal Pressure Thara Gopinath
2019-12-12 4:11 ` [Patch v6 1/7] sched/pelt.c: Add support to track thermal pressure Thara Gopinath
2019-12-16 13:43 ` Peter Zijlstra
2019-12-17 12:54 ` Dietmar Eggemann
[not found] ` <CALD-y_xHS7CaZ8SU--VP5+2F5Y8cVb4sw0XuG+JUpP_jxE7yuQ@mail.gmail.com>
2020-01-09 12:24 ` Dietmar Eggemann
2019-12-23 17:56 ` Ionela Voinescu
2020-01-02 14:40 ` Thara Gopinath
2019-12-12 4:11 ` [Patch v6 2/7] sched: Add hook to read per cpu " Thara Gopinath
2019-12-16 14:35 ` Peter Zijlstra
2019-12-17 12:54 ` Dietmar Eggemann
2019-12-12 4:11 ` [Patch v6 3/7] Add infrastructure to store and update instantaneous " Thara Gopinath
2019-12-16 14:37 ` Peter Zijlstra
2019-12-17 12:54 ` Dietmar Eggemann
2019-12-23 17:50 ` Ionela Voinescu
2019-12-12 4:11 ` [Patch v6 4/7] sched/fair: Enable periodic update of average " Thara Gopinath
2019-12-16 14:39 ` Peter Zijlstra
2019-12-16 17:59 ` Quentin Perret
2019-12-17 12:57 ` Dietmar Eggemann
2019-12-27 15:22 ` Thara Gopinath
2019-12-12 4:11 ` [Patch v6 5/7] sched/fair: update cpu_capacity to reflect " Thara Gopinath
2019-12-17 12:54 ` Dietmar Eggemann
2019-12-23 17:52 ` Ionela Voinescu
2019-12-12 4:11 ` [Patch v6 6/7] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping Thara Gopinath
2019-12-23 17:54 ` Ionela Voinescu
2019-12-12 4:11 ` [Patch v6 7/7] sched/fair: Enable tuning of decay period Thara Gopinath
2019-12-23 17:55 ` Ionela Voinescu
2019-12-16 14:56 ` [Patch v6 0/7] Introduce Thermal Pressure Peter Zijlstra
2020-01-11 15:04 ` Thara Gopinath [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5E19E404.1020601@linaro.org \
--to=thara.gopinath@linaro.org \
--cc=amit.kachhap@gmail.com \
--cc=amit.kucheria@verdurent.com \
--cc=daniel.lezcano@linaro.org \
--cc=ionela.voinescu@arm.com \
--cc=javi.merino@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qperret@google.com \
--cc=rui.zhang@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.