linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Thara Gopinath <thara.gopinath@linaro.org>,
	mingo@redhat.com, peterz@infradead.org, rui.zhang@intel.com
Cc: linux-kernel@vger.kernel.org, amit.kachhap@gmail.com,
	viresh.kumar@linaro.org, javi.merino@kernel.org,
	edubezval@gmail.com, daniel.lezcano@linaro.org,
	vincent.guittot@linaro.org, nicolas.dechesne@linaro.org,
	bjorn.andersson@linaro.org, dietmar.eggemann@arm.com
Subject: Re: [PATCH V2 0/3] Introduce Thermal Pressure
Date: Tue, 30 Apr 2019 15:39:00 +0100	[thread overview]
Message-ID: <8371be92-635b-1979-b1cd-6985ecb4811f@arm.com> (raw)
In-Reply-To: <8eed9601-8bbb-9f62-f786-f08bd4a72907@arm.com>

Hi Thara,

On 29/04/2019 14:29, Ionela Voinescu wrote:
> Hi Thara,
> 
>>
>> 			Hackbench: (1 group , 30000 loops, 10 runs)
>> 				Result            Standard Deviation
>> 				(Time Secs)        (% of mean)
>>
>> No Thermal Pressure             10.21                   7.99%
>>
>> Instantaneous thermal pressure  10.16                   5.36%
>>
>> Thermal Pressure Averaging
>> using PELT fmwk                 9.88                    3.94%
>>
>> Thermal Pressure Averaging
>> non-PELT Algo. Decay : 500 ms   9.94                    4.59%
>>
>> Thermal Pressure Averaging
>> non-PELT Algo. Decay : 250 ms   7.52                    5.42%
>>
>> Thermal Pressure Averaging
>> non-PELT Algo. Decay : 125 ms   9.87                    3.94%
>>
>>
> 
> I'm trying your patches on my Hikey960 and I'm getting different results
> than the ones here.
> 
> I'm running with the step-wise governor, enabled only on the big cores.
> The decay period is set to 250ms.
> 
> The result for hackbench is:
> 
> # ./hackbench -g 1 -l 30000
> Running in process mode with 1 groups using 40 file descriptors each (== 40 tasks)
> Each sender will pass 30000 messages of 100 bytes
> Time: 20.756
> 
> During the run I see the little cores running at maximum frequency
> (1.84GHz) while the big cores run mostly at 1.8GHz, only sometimes capped
> at 1.42GHz. There should not be any capacity inversion.
> The temperature is kept around 75 degrees (73 to 77 degrees).
> 
> I don't have any kind of active cooling (no fans on the board), only a
> heatsink on the SoC.
> 
> But as you see my results(~20s) are very far from the 7-10s in your
> results.
> 
> Do you see anything wrong with this process? Can you give me more
> details on your setup that I can use to test on my board?
> 

I've found that my poor results above were due to debug options
mistakenly left enabled in the defconfig. Sorry about that!

After cleaning it up I'm getting results around 5.6s for this test case.
I've run 50 iterations for each test, with 90s cool down period between
them.


 			Hackbench: (1 group , 30000 loops, 50 runs)
 				Result            Standard Deviation
 				(Time Secs)        (% of mean)

 No Thermal Pressure(step_wise)  5.644                   7.760%
 No Thermal Pressure(IPA)        5.677                   9.062%

 Thermal Pressure Averaging
 non-PELT Algo. Decay : 250 ms   5.627                   5.593%
 (step-wise, bigs capped only)

 Thermal Pressure Averaging
 non-PELT Algo. Decay : 250 ms   5.690                   3.738%
 (IPA)

All of the results above are within 1.1% difference with a
significantly higher standard deviation.

I wanted to run this initially to validate my setup and understand
if there is any conclusion we can draw from a test like this, that
floods the CPUs with tasks. Looking over the traces, the tasks are
running almost back to back, trying to use all available resources,
on all the CPUs.
Therefore, I doubt that there could be better decisions that could be
made, knowing about thermal pressure, for this usecase.

I'll try next some capacity inversion usecase and post the results when
they are ready.

Hope it helps,
Ionela.


> Thank you,
> Ionela.
> 

  reply	other threads:[~2019-04-30 14:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16 19:38 [PATCH V2 0/3] Introduce Thermal Pressure Thara Gopinath
2019-04-16 19:38 ` [PATCH V2 1/3] Calculate " Thara Gopinath
2019-04-18 10:14   ` Quentin Perret
2019-04-24  4:13     ` Thara Gopinath
2019-04-24 16:38   ` Peter Zijlstra
2019-04-24 16:45   ` Peter Zijlstra
2019-04-25 10:57   ` Quentin Perret
2019-04-25 12:45     ` Vincent Guittot
2019-04-25 12:47       ` Quentin Perret
2019-04-26 14:17       ` Thara Gopinath
2019-05-08 12:41         ` Quentin Perret
2019-04-16 19:38 ` [PATCH V2 2/3] sched/fair: update cpu_capcity to reflect thermal pressure Thara Gopinath
2019-04-16 19:38 ` [PATCH V3 3/3] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping Thara Gopinath
2019-04-18  9:48   ` Quentin Perret
2019-04-23 22:38     ` Thara Gopinath
2019-04-24 15:56       ` Ionela Voinescu
2019-04-26 10:24         ` Thara Gopinath
2019-04-25 10:45       ` Quentin Perret
2019-04-25 12:04         ` Vincent Guittot
2019-04-25 12:50           ` Quentin Perret
2019-04-26 13:47         ` Thara Gopinath
2019-04-24 16:47   ` Peter Zijlstra
2019-04-17  5:36 ` [PATCH V2 0/3] Introduce Thermal Pressure Ingo Molnar
2019-04-17  5:55   ` Ingo Molnar
2019-04-17 17:28     ` Thara Gopinath
2019-04-17 17:18   ` Thara Gopinath
2019-04-17 18:29     ` Ingo Molnar
2019-04-18  0:07       ` Thara Gopinath
2019-04-18  9:22       ` Quentin Perret
2019-04-24 16:34       ` Peter Zijlstra
2019-04-25 17:33         ` Ingo Molnar
2019-04-25 17:44           ` Ingo Molnar
2019-04-26  7:08             ` Vincent Guittot
2019-04-26  8:35               ` Ingo Molnar
2019-04-24 15:57 ` Ionela Voinescu
2019-04-26 11:50   ` Thara Gopinath
2019-04-26 14:46     ` Ionela Voinescu
2019-04-29 13:29 ` Ionela Voinescu
2019-04-30 14:39   ` Ionela Voinescu [this message]
2019-04-30 16:10     ` Thara Gopinath
2019-05-02 10:44       ` Ionela Voinescu
2019-04-30 15:57   ` Thara Gopinath
2019-04-30 16:02     ` Thara Gopinath

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=8371be92-635b-1979-b1cd-6985ecb4811f@arm.com \
    --to=ionela.voinescu@arm.com \
    --cc=amit.kachhap@gmail.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=edubezval@gmail.com \
    --cc=javi.merino@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nicolas.dechesne@linaro.org \
    --cc=peterz@infradead.org \
    --cc=rui.zhang@intel.com \
    --cc=thara.gopinath@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).