All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thara Gopinath <thara.gopinath@linaro.org>
To: Ionela Voinescu <ionela.voinescu@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Eduardo Valentin <edubezval@gmail.com>,
	Quentin Perret <qperret@google.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Amit Kachhap <amit.kachhap@gmail.com>,
	Javi Merino <javi.merino@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [Patch v4 5/6] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping
Date: Fri, 1 Nov 2019 17:04:47 -0400	[thread overview]
Message-ID: <5DBC9DEF.6030007@linaro.org> (raw)
In-Reply-To: <20191101154612.GA4884@e108754-lin>

On 11/01/2019 11:47 AM, Ionela Voinescu wrote:
> Hi guys,
> 
> On Thursday 31 Oct 2019 at 17:38:25 (+0100), Vincent Guittot wrote:
>> On Thu, 31 Oct 2019 at 17:29, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
>>>
>>> On 22.10.19 22:34, Thara Gopinath wrote:
>>>> Thermal governors can request for a cpu's maximum supported frequency
>>>> to be capped in case of an overheat event. This in turn means that the
>>>> maximum capacity available for tasks to run on the particular cpu is
>>>> reduced. Delta between the original maximum capacity and capped
>>>> maximum capacity is known as thermal pressure. Enable cpufreq cooling
>>>> device to update the thermal pressure in event of a capped
>>>> maximum frequency.
>>>>
>>>> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
>>>> ---
>>>>  drivers/thermal/cpu_cooling.c | 31 +++++++++++++++++++++++++++++--
>>>>  1 file changed, 29 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>>>> index 391f397..2e6a979 100644
>>>> --- a/drivers/thermal/cpu_cooling.c
>>>> +++ b/drivers/thermal/cpu_cooling.c
>>>> @@ -218,6 +218,23 @@ static u32 cpu_power_to_freq(struct cpufreq_cooling_device *cpufreq_cdev,
>>>>  }
>>>>
>>>>  /**
>>>> + * update_sched_max_capacity - update scheduler about change in cpu
>>>> + *                                   max frequency.
>>>> + * @policy - cpufreq policy whose max frequency is capped.
>>>> + */
>>>> +static void update_sched_max_capacity(struct cpumask *cpus,
>>>> +                                   unsigned int cur_max_freq,
>>>> +                                   unsigned int max_freq)
>>>> +{
>>>> +     int cpu;
>>>> +     unsigned long capacity = (cur_max_freq << SCHED_CAPACITY_SHIFT) /
>>>> +                               max_freq;
>>>> +
>>>> +     for_each_cpu(cpu, cpus)
>>>> +             update_thermal_pressure(cpu, capacity);
>>>> +}
>>>> +
>>>> +/**
>>>>   * get_load() - get load for a cpu since last updated
>>>>   * @cpufreq_cdev:    &struct cpufreq_cooling_device for this cpu
>>>>   * @cpu:     cpu number
>>>> @@ -320,6 +337,7 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
>>>>                                unsigned long state)
>>>>  {
>>>>       struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
>>>> +     int ret;
>>>>
>>>>       /* Request state should be less than max_level */
>>>>       if (WARN_ON(state > cpufreq_cdev->max_level))
>>>> @@ -331,8 +349,17 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
>>>>
>>>>       cpufreq_cdev->cpufreq_state = state;
>>>>
>>>> -     return dev_pm_qos_update_request(&cpufreq_cdev->qos_req,
>>>> -                             cpufreq_cdev->freq_table[state].frequency);
>>>> +     ret = dev_pm_qos_update_request
>>>> +                             (&cpufreq_cdev->qos_req,
>>>> +                              cpufreq_cdev->freq_table[state].frequency);
>>>> +
>>>> +     if (ret > 0)
>>>> +             update_sched_max_capacity
>>>> +                             (cpufreq_cdev->policy->cpus,
>>>> +                              cpufreq_cdev->freq_table[state].frequency,
>>>> +                              cpufreq_cdev->policy->cpuinfo.max_freq);
>>>> +
>>>> +     return ret;
>>>>  }
>>>>
>>>>  /**
>>>>
>>>
>>> Why not getting rid of update_sched_max_capacity() entirely and call
>>> update_thermal_pressure() in cpu_cooling.c directly? Saves one level in
>>> the call chain and would mean less code for this feature.
>>
>> But you add complexity in update_thermal_pressure which now has to
>> deal with a cpumask and to compute some frequency ratio
>> IMHO, it's cleaner to keep update_thermal_pressure simple as it is now
>>
> 
> How about removing update_thermal_pressure altogether and doing all the
> work in update_sched_max_capacity? That is, have
> update_sched_max_capacity compute the capped_freq_ratio, do the
> normalization, and set it per_cpu for all CPUs in the frequency domain.
> You'll save some calculations that you're now doing in
> update_thermal_pressure for each cpu and you avoid shifting back and
> forth.

Yes.  I can pass the delta to update_thermal_pressure. I will still want
to keep update_thermal_pressure and a per cpu variable in fair.c to
store this.
> 
> If you're doing so it would be worth renaming update_sched_max_capacity
> to something like update_sched_thermal_pressure.
Will do.


-- 
Warm Regards
Thara

  reply	other threads:[~2019-11-01 21:04 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 [this message]
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
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=5DBC9DEF.6030007@linaro.org \
    --to=thara.gopinath@linaro.org \
    --cc=amit.kachhap@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=edubezval@gmail.com \
    --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 \
    /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.