public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Michael Turquette <mturquette@baylibre.com>,
	peterz@infradead.org, rjw@rjwysocki.net
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Juri.Lelli@arm.com, steve.muckle@linaro.org,
	morten.rasmussen@arm.com, vincent.guittot@linaro.org,
	Michael Turquette <mturquette+renesas@baylibre.com>
Subject: Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity
Date: Tue, 15 Mar 2016 19:13:58 +0000	[thread overview]
Message-ID: <56E85EF6.5040005@arm.com> (raw)
In-Reply-To: <1457932932-28444-9-git-send-email-mturquette+renesas@baylibre.com>

On 14/03/16 05:22, Michael Turquette wrote:
> arch_scale_freq_capacity is weird. It specifies an arch hook for an
> implementation that could easily vary within an architecture or even a
> chip family.
> 
> This patch helps to mitigate this weirdness by defaulting to the
> cpufreq-provided implementation, which should work for all cases where
> CONFIG_CPU_FREQ is set.
> 
> If CONFIG_CPU_FREQ is not set, then try to use an implementation
> provided by the architecture. Failing that, fall back to
> SCHED_CAPACITY_SCALE.
> 
> It may be desirable for cpufreq drivers to specify their own
> implementation of arch_scale_freq_capacity in the future. The same is
> true for platform code within an architecture. In both cases an
> efficient implementation selector will need to be created and this patch
> adds a comment to that effect.

For me this independence of the scheduler code towards the actual
implementation of the Frequency Invariant Engine (FEI) was actually a
feature.

In EAS RFC5.2 (linux-arm.org/linux-power.git energy_model_rfc_v5.2 ,
which hasn't been posted to LKML) we establish the link in the ARCH code
(arch/arm64/include/asm/topology.h).

#ifdef CONFIG_CPU_FREQ
#define arch_scale_freq_capacity cpufreq_scale_freq_capacity
...
+#endif

> 
> Signed-off-by: Michael Turquette <mturquette+renesas@baylibre.com>
> ---
>  kernel/sched/sched.h | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 469d11d..37502ea 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1368,7 +1368,21 @@ static inline int hrtick_enabled(struct rq *rq)
>  #ifdef CONFIG_SMP
>  extern void sched_avg_update(struct rq *rq);
>  
> -#ifndef arch_scale_freq_capacity
> +/*
> + * arch_scale_freq_capacity can be implemented by cpufreq, platform code or
> + * arch code. We select the cpufreq-provided implementation first. If it
> + * doesn't exist then we default to any other implementation provided from
> + * platform/arch code. If those do not exist then we use the default
> + * SCHED_CAPACITY_SCALE value below.
> + *
> + * Note that if cpufreq drivers or platform/arch code have competing
> + * implementations it is up to those subsystems to select one at runtime with
> + * an efficient solution, as we cannot tolerate the overhead of indirect
> + * functions (e.g. function pointers) in the scheduler fast path
> + */
> +#ifdef CONFIG_CPU_FREQ
> +#define arch_scale_freq_capacity cpufreq_scale_freq_capacity
> +#elif !defined(arch_scale_freq_capacity)
>  static __always_inline
>  unsigned long arch_scale_freq_capacity(struct sched_domain *sd, int cpu)
>  {
> 

  reply	other threads:[~2016-03-15 19:14 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14  5:22 [PATCH 0/8] schedutil enhancements Michael Turquette
2016-03-14  5:22 ` [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update() Michael Turquette
2016-03-15 21:14   ` Peter Zijlstra
     [not found]     ` <20160315214545.30639.98727@quark.deferred.io>
2016-03-15 21:49       ` Peter Zijlstra
2016-03-16  8:00   ` Peter Zijlstra
2016-03-14  5:22 ` [PATCH 2/8] sched/fair: add margin to utilization update Michael Turquette
2016-03-15 21:16   ` Peter Zijlstra
     [not found]     ` <20160315212848.30639.38747@quark.deferred.io>
2016-03-15 21:43       ` Peter Zijlstra
2016-03-16  2:52   ` Steve Muckle
2016-03-16 22:12     ` Michael Turquette
2016-03-14  5:22 ` [PATCH 3/8] sched/cpufreq: new cfs capacity margin helpers Michael Turquette
2016-03-15 21:17   ` Peter Zijlstra
2016-03-14  5:22 ` [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Michael Turquette
2016-03-15 21:20   ` Peter Zijlstra
     [not found]     ` <20160315214043.30639.75507@quark.deferred.io>
2016-03-15 21:48       ` Peter Zijlstra
     [not found]         ` <20160315223701.30639.43127@quark.deferred.io>
2016-03-16  3:36           ` Steve Muckle
2016-03-16  8:05             ` Peter Zijlstra
2016-03-16 10:02               ` Juri Lelli
2016-03-16 17:55                 ` Steve Muckle
2016-03-16 22:05                   ` Michael Turquette
2016-03-17  9:40                   ` Juri Lelli
2016-03-17 13:55                     ` Steve Muckle
2016-03-17 15:53                       ` Patrick Bellasi
2016-03-17 17:54                         ` Juri Lelli
2016-03-17 18:56                           ` Michael Turquette
2016-03-17 22:34                             ` Rafael J. Wysocki
2016-03-16 12:45               ` Rafael J. Wysocki
2016-03-16 22:03             ` Michael Turquette
2016-03-14  5:22 ` [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util Michael Turquette
2016-03-15 21:25   ` Peter Zijlstra
     [not found]     ` <20160315220609.30639.67271@quark.deferred.io>
2016-03-16  3:55       ` Steve Muckle
2016-03-16  7:41       ` Peter Zijlstra
2016-03-16  8:29         ` Vincent Guittot
2016-03-16  8:53           ` Peter Zijlstra
2016-03-16  9:16             ` Vincent Guittot
2016-03-16 12:39             ` Rafael J. Wysocki
2016-03-16 13:10               ` Peter Zijlstra
2016-03-16 13:23                 ` Rafael J. Wysocki
2016-03-16 13:43                   ` Peter Zijlstra
2016-03-14  5:22 ` [PATCH 6/8] cpufreq/schedutil: sum per-sched class utilization Michael Turquette
2016-03-15 21:29   ` Peter Zijlstra
     [not found]     ` <20160315220951.30639.12872@quark.deferred.io>
2016-03-16  7:38       ` Peter Zijlstra
2016-03-16 18:20         ` Steve Muckle
2016-03-16 18:36           ` Peter Zijlstra
2016-03-16 19:12             ` Steve Muckle
2016-03-14  5:22 ` [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support Michael Turquette
2016-03-15 19:13   ` Dietmar Eggemann
2016-03-15 20:19     ` Michael Turquette
2016-03-15 21:32       ` Peter Zijlstra
2016-03-16 18:33       ` Dietmar Eggemann
2016-03-15 21:34   ` Peter Zijlstra
2016-03-14  5:22 ` [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Michael Turquette
2016-03-15 19:13   ` Dietmar Eggemann [this message]
2016-03-15 20:46     ` Michael Turquette
2016-03-16 19:44       ` Dietmar Eggemann
2016-03-16 20:07         ` Peter Zijlstra
2016-03-16 21:32           ` Rafael J. Wysocki
2016-03-15 21:37   ` Peter Zijlstra
     [not found]     ` <20160315222721.30639.28332@quark.deferred.io>
2016-03-16  7:47       ` Peter Zijlstra
2016-03-16 12:41         ` Peter Zijlstra
2016-03-16  0:08 ` [PATCH 0/8] schedutil enhancements Rafael J. Wysocki

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=56E85EF6.5040005@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=Juri.Lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=mturquette+renesas@baylibre.com \
    --cc=mturquette@baylibre.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=steve.muckle@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