All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thara Gopinath <thara.gopinath@linaro.org>
To: Quentin Perret <quentin.perret@arm.com>
Cc: mingo@redhat.com, peterz@infradead.org, rui.zhang@intel.com,
	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 V3 3/3] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping
Date: Tue, 23 Apr 2019 18:38:46 -0400	[thread overview]
Message-ID: <5CBF93F6.8000109@linaro.org> (raw)
In-Reply-To: <20190418094833.owlobrx6x5gclvhy@queper01-lin>

On 04/18/2019 05:48 AM, Quentin Perret wrote:
> On Tuesday 16 Apr 2019 at 15:38:41 (-0400), Thara Gopinath wrote:
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> @@ -177,6 +178,9 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb,
>>  
>>  		if (policy->max > clipped_freq)
>>  			cpufreq_verify_within_limits(policy, 0, clipped_freq);
>> +
>> +		sched_update_thermal_pressure(policy->cpus,
>> +				policy->max, policy->cpuinfo.max_freq);
> 
> Is this something we could do this CPUFreq ? Directly in
> cpufreq_verify_within_limits() perhaps ?
> 
> That would re-define the 'thermal pressure' framework in a more abstract
> way and make the scheduler look at 'frequency capping' events,
> regardless of the reason for capping.
> 
> That would reflect user-defined frequency constraint into cpu_capacity,
> in addition to the thermal stuff. I'm not sure if there is another use
> case for frequency capping ?
Hi Quentin,
Thanks for the review. Sorry for the delay in response as I was on
vacation for the past few days.
I think there is one major difference between user-defined frequency
constraints and frequency constraints due to thermal events in terms of
the time period the system spends in the the constraint state.
Typically, a user constraint lasts for seconds if not minutes and I
think in this case cpu_capacity_orig should reflect this constraint and
not cpu_capacity like this patch set. Also, in case of the user
constraint, there is possibly no need to accumulate and average the
capacity constraints and instantaneous values can be directly applied to
cpu_capacity_orig. On the other hand thermal pressure is more spiky and
sometimes in the order of ms and us requiring the accumulating and
averaging.
> 
> Perhaps the Intel boost stuff could be factored in there ? That is,
> at times when the boost freq is not reachable capacity_of() would appear
> smaller ... Unless this wants to be reflected instantaneously ?
Again, do you think intel boost is more applicable to be reflected in
cpu_capacity_orig and not cpu_capacity?
> 
> Thoughts ?
> Quentin
> 


-- 
Regards
Thara

  reply	other threads:[~2019-04-23 22:38 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 [this message]
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
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=5CBF93F6.8000109@linaro.org \
    --to=thara.gopinath@linaro.org \
    --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=quentin.perret@arm.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.