All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Thara Gopinath <thara.gopinath@linaro.org>
Cc: mingo@redhat.com, peterz@infradead.org,
	vincent.guittot@linaro.org, rui.zhang@intel.com,
	edubezval@gmail.com, qperret@google.com,
	linux-kernel@vger.kernel.org, amit.kachhap@gmail.com,
	javi.merino@kernel.org, daniel.lezcano@linaro.org
Subject: Re: [Patch v4 6/6] sched: thermal: Enable tuning of decay period
Date: Tue, 5 Nov 2019 21:29:01 +0000	[thread overview]
Message-ID: <20191105212735.GA32353@e108754-lin> (raw)
In-Reply-To: <5DC1DADE.60603@linaro.org>

On Tuesday 05 Nov 2019 at 15:26:06 (-0500), Thara Gopinath wrote:
> On 11/04/2019 11:12 AM, Ionela Voinescu wrote:
> > Hi Thara,
> > 
> > On Tuesday 22 Oct 2019 at 16:34:25 (-0400), Thara Gopinath wrote:
> >> Thermal pressure follows pelt signas which means the
> >> decay period for thermal pressure is the default pelt
> >> decay period. Depending on soc charecteristics and thermal
> >> activity, it might be beneficial to decay thermal pressure
> >> slower, but still in-tune with the pelt signals.
> > 
> > I wonder if it can be beneficial to decay thermal pressure faster as
> > well.
> > 
> > This implementation makes 32 (LOAD_AVG_PERIOD) the minimum half-life
> > of the thermal pressure samples. This results in more than 100ms for a
> > sample to decay significantly and therefore let's say it can take more
> > than 100ms for capacity to return to (close to) max when the CPU is no
> > longer capped. This value seems high to me considering that a minimum
> > value should result in close to 'instantaneous' behaviour, when there
> > are thermal capping mechanisms that can react in ~20ms (hikey960 has a
> > polling delay of 25ms, if I'm remembering correctly).
> > 
> > I agree 32ms seems like a good default but given that you've made this
> > configurable as to give users options, I'm wondering if it would be
> > better to cover a wider range.
> >

[...]

> 
> Hi Ionela,
>

[...]

> 
> Regarding a slower decay, we need a strong case for it.
> 
>

I think you mean faster decay, if you refer to my comment above.

To be blunt, I'm not sure there is a strong case for either kind of
dacay, if we look at the test results only. There is a theoretical case
for both, in my opinion and given that the purpose of this patch is to
give options to platform with different thermal characteristics, I do
believe it's worth providing a good range of options for the decay
period.

Thanks,
Ionela.

> 
> -- 
> Warm Regards
> Thara

  reply	other threads:[~2019-11-05 21:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22 20:34 [Patch v4 0/6] Introduce Thermal Pressure Thara Gopinath
2019-10-22 20:34 ` [Patch v4 1/6] sched/pelt.c: Add support to track thermal pressure Thara Gopinath
2019-10-31  9:47   ` Ionela Voinescu
2019-10-22 20:34 ` [Patch v4 2/6] sched: Add infrastructure to store and update instantaneous " Thara Gopinath
2019-10-28 15:21   ` Peter Zijlstra
2019-10-30 21:37     ` Thara Gopinath
2019-11-01 12:17   ` Dietmar Eggemann
2019-11-01 20:57     ` Thara Gopinath
2019-11-04 17:29       ` Dietmar Eggemann
2019-11-04 17:34         ` Vincent Guittot
2019-11-04 17:41           ` Dietmar Eggemann
2019-11-04 17:48             ` Vincent Guittot
2019-10-22 20:34 ` [Patch v4 3/6] sched/fair: Enable CFS periodic tick to update " Thara Gopinath
2019-10-28 15:24   ` Peter Zijlstra
2019-10-28 15:27     ` Peter Zijlstra
2019-10-30 21:41     ` Thara Gopinath
2019-10-31 16:11   ` Dietmar Eggemann
2019-10-31 16:46     ` Thara Gopinath
2019-10-22 20:34 ` [Patch v4 4/6] sched/fair: update cpu_capcity to reflect " Thara Gopinath
2019-10-23 12:28   ` Qais Yousef
2019-10-28 15:30     ` Peter Zijlstra
2019-10-31 10:53       ` Qais Yousef
2019-10-31 15:38         ` Dietmar Eggemann
2019-10-31 15:48           ` Vincent Guittot
2019-10-31 16:17             ` Dietmar Eggemann
2019-10-31 16:31               ` Vincent Guittot
2019-10-31 16:44                 ` Dietmar Eggemann
2019-10-31 16:03         ` Thara Gopinath
2019-10-31 16:56           ` Qais Yousef
2019-10-22 20:34 ` [Patch v4 5/6] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping Thara Gopinath
2019-10-28 15:33   ` Peter Zijlstra
2019-10-31 16:29   ` Dietmar Eggemann
2019-10-31 16:38     ` Vincent Guittot
2019-11-01 15:47       ` Ionela Voinescu
2019-11-01 21:04         ` Thara Gopinath
2019-11-04 14:41           ` Ionela Voinescu
2019-10-31 16:46     ` Thara Gopinath
2019-10-22 20:34 ` [Patch v4 6/6] sched: thermal: Enable tuning of decay period Thara Gopinath
2019-10-28 15:42   ` Peter Zijlstra
2019-11-04 16:12   ` Ionela Voinescu
2019-11-05 20:26     ` Thara Gopinath
2019-11-05 21:29       ` Ionela Voinescu [this message]
2019-10-29 15:34 ` [Patch v4 0/6] Introduce Thermal Pressure Daniel Lezcano
2019-10-31 10:07   ` Ionela Voinescu
2019-10-31 11:54     ` Daniel Lezcano
2019-10-31 12:57       ` Ionela Voinescu
2019-10-31 17:48         ` Daniel Lezcano
2019-10-31  9:44 ` Ionela Voinescu
2019-10-31 16:41   ` Thara Gopinath
2019-10-31 16:52     ` Thara Gopinath
2019-11-05 21:04     ` Ionela Voinescu

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=20191105212735.GA32353@e108754-lin \
    --to=ionela.voinescu@arm.com \
    --cc=amit.kachhap@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=edubezval@gmail.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=thara.gopinath@linaro.org \
    --cc=vincent.guittot@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.