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>
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: Mon, 4 Nov 2019 16:12:14 +0000	[thread overview]
Message-ID: <20191104161035.GA6680@e108754-lin> (raw)
In-Reply-To: <1571776465-29763-7-git-send-email-thara.gopinath@linaro.org>

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.

> One way to achieve this is to provide a command line parameter
> to set the decay coefficient to an integer between 0 and 10.
> 
> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
> ---
> v3->v4:
> 	- Removed the sysctl setting to tune decay period and instead
> 	  introduced a command line parameter to control it. The rationale
> 	  here being changing decay period of a PELT signal runtime can
> 	  result in a skewed average value for atleast some cycles.
> 
>  Documentation/admin-guide/kernel-parameters.txt |  5 +++++
>  kernel/sched/thermal.c                          | 25 ++++++++++++++++++++++++-
>  2 files changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index a84a83f..61d7baa 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4273,6 +4273,11 @@
>  			incurs a small amount of overhead in the scheduler
>  			but is useful for debugging and performance tuning.
>  
> +	sched_thermal_decay_coeff=
> +			[KNL, SMP] Set decay coefficient for thermal pressure signal.
> +			Format: integer betweer 0 and 10
> +			Default is 0.
> +
>  	skew_tick=	[KNL] Offset the periodic timer tick per cpu to mitigate
>  			xtime_lock contention on larger systems, and/or RCU lock
>  			contention on all systems with CONFIG_MAXSMP set.
> diff --git a/kernel/sched/thermal.c b/kernel/sched/thermal.c
> index 0c84960..0da31e1 100644
> --- a/kernel/sched/thermal.c
> +++ b/kernel/sched/thermal.c
> @@ -10,6 +10,28 @@
>  #include "pelt.h"
>  #include "thermal.h"
>  
> +/**
> + * By default the decay is the default pelt decay period.
> + * The decay coefficient can change is decay period in
> + * multiples of 32.

This description has to be corrected as well, as per Peter's comment.

Also, it might be good not to use the value 32 directly but to mention
that the decay period is a shift of LOAD_AVG_PERIOD. If that changes,
the translation from decay shift to decay period below will change as
well.

Thank you,
Ionela.

> + *   Decay coefficient    Decay period(ms)
> + *	0			32
> + *	1			64
> + *	2			128
> + *	3			256
> + *	4			512
> + */
> +static int sched_thermal_decay_coeff;
> +
> +static int __init setup_sched_thermal_decay_coeff(char *str)
> +{
> +	if (kstrtoint(str, 0, &sched_thermal_decay_coeff))
> +		pr_warn("Unable to set scheduler thermal pressure decay coefficient\n");
> +
> +	return 1;
> +}
> +__setup("sched_thermal_decay_coeff=", setup_sched_thermal_decay_coeff);
> +
>  static DEFINE_PER_CPU(unsigned long, delta_capacity);
>  
>  /**
> @@ -40,6 +62,7 @@ void update_thermal_pressure(int cpu, u64 capped_freq_ratio)
>   */
>  void trigger_thermal_pressure_average(struct rq *rq)
>  {
> -	update_thermal_load_avg(rq_clock_task(rq), rq,
> +	update_thermal_load_avg(rq_clock_task(rq) >>
> +				sched_thermal_decay_coeff, rq,
>  				per_cpu(delta_capacity, cpu_of(rq)));
>  }
> -- 
> 2.1.4
> 

  parent reply	other threads:[~2019-11-04 16:12 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 [this message]
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=20191104161035.GA6680@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 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).