All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Thara Gopinath <thara.gopinath@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	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: Thu, 31 Oct 2019 17:38:25 +0100	[thread overview]
Message-ID: <CAKfTPtCpZq61gQVpATtTdg5hDA+tP4bF6xPMsvHYUMoY+H-6FQ@mail.gmail.com> (raw)
In-Reply-To: <2b19d7da-412c-932f-7251-110eadbef3e3@arm.com>

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

>
> Just compile tested on arm64:
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 3211b4d3a899..bf36995013b0 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -217,23 +217,6 @@ static u32 cpu_power_to_freq(struct
> cpufreq_cooling_device *cpufreq_cdev,
>         return freq_table[i - 1].frequency;
>  }
>
> -/**
> - * 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
> @@ -353,7 +336,7 @@ static int cpufreq_set_cur_state(struct
> thermal_cooling_device *cdev,
>                                 cpufreq_cdev->freq_table[state].frequency);
>
>         if (ret > 0)
> -               update_sched_max_capacity
> +               update_thermal_pressure
>                                 (cpufreq_cdev->policy->cpus,
>                                  cpufreq_cdev->freq_table[state].frequency,
>                                  cpufreq_cdev->policy->cpuinfo.max_freq);
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 55dfe9634f67..5707813c7621 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1985,9 +1985,9 @@ static inline void rseq_syscall(struct pt_regs *regs)
>  #endif
>
>  #ifdef CONFIG_SMP
> -void update_thermal_pressure(int cpu, u64 capacity);
> +void update_thermal_pressure(struct cpumask *cpus, unsigned int cur,
> unsigned int max);
>  #else
> -static inline void update_thermal_pressure(int cpu, u64 capacity)
> +static inline void update_thermal_pressure(struct cpumask *cpus,
> unsigned int cur, unsigned int max);
>  {
>  }
>  #endif
> diff --git a/kernel/sched/thermal.c b/kernel/sched/thermal.c
> index 0da31e12a5ff..691bdd79597a 100644
> --- a/kernel/sched/thermal.c
> +++ b/kernel/sched/thermal.c
> @@ -43,17 +43,16 @@ static DEFINE_PER_CPU(unsigned long, delta_capacity);
>   * the arch_scale_cpu_capacity and capped capacity is stored in per cpu
>   * delta_capacity.
>   */
> -void update_thermal_pressure(int cpu, u64 capped_freq_ratio)
> +void update_thermal_pressure(struct cpumask *cpus, unsigned int cur,
> unsigned int max)
>  {
> -       unsigned long __capacity, delta;
> +       int cpu;
>
> -       /* Normalize the capped freq ratio */
> -       __capacity = (capped_freq_ratio * arch_scale_cpu_capacity(cpu)) >>
> -
> SCHED_CAPACITY_SHIFT;
> -       delta = arch_scale_cpu_capacity(cpu) -  __capacity;
> -       pr_debug("updating cpu%d thermal pressure to %lu\n", cpu, delta);
> +       for_each_cpu(cpu, cpus) {
> +               unsigned long scale_cap = arch_scale_cpu_capacity(cpu);
> +               unsigned long cur_cap = cur * scale_cap / max;
>
> -       per_cpu(delta_capacity, cpu) = delta;
> +               per_cpu(delta_capacity, cpu) = scale_cap - cur_cap;
> +       }
>  }

  reply	other threads:[~2019-10-31 16:38 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 [this message]
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
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=CAKfTPtCpZq61gQVpATtTdg5hDA+tP4bF6xPMsvHYUMoY+H-6FQ@mail.gmail.com \
    --to=vincent.guittot@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=thara.gopinath@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.