Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1681394 > unrolled thread

[RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
    [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
      Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all  CPUs when deciding next freq Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-07 11:00 +0200
      Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all  CPUs when deciding next freq Peter Zijlstra <peterz@infradead.org> - 2017-07-11 18:20 +0200
        Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all  CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-07-11 19:20 +0200
    [RFC PATCH v1 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
      Re: [RFC PATCH v1 7/8] sched/sched.h: move  arch_scale_{freq,cpu}_capacity outside CONFIG_SMP Steven Rostedt <rostedt@goodmis.org> - 2017-07-08 00:10 +0200
    [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
      Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals Joel Fernandes <joelaf@google.com> - 2017-07-07 05:30 +0200
      Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization  signals Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-07 11:00 +0200
        Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization  signals Juri Lelli <juri.lelli@arm.com> - 2017-07-07 13:00 +0200
          Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals Joel Fernandes <joelaf@google.com> - 2017-07-10 09:50 +0200
      Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization  signals Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-10 09:10 +0200
    [RFC PATCH v1 2/8] sched/deadline: move cpu frequency selection triggering points Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
      Re: [RFC PATCH v1 2/8] sched/deadline: move cpu frequency selection  triggering points Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-07 09:30 +0200
    Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Steven Rostedt <rostedt@goodmis.org> - 2017-07-06 18:00 +0200
      Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Juri Lelli <juri.lelli@arm.com> - 2017-07-06 18:10 +0200
      Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Peter Zijlstra <peterz@infradead.org> - 2017-07-06 18:20 +0200
    Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-07-06 23:20 +0200

#1681394 — [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

Hi,

v1 of the RFC set implementing frequency/cpu invariance and OPP selection for
SCHED_DEADLINE [1]. The set is based on tip/sched/core as of today
(72298e5c92c5), which now already includes Luca's "CPU reclaiming for
SCHED_DEADLINE".

Thanks a lot for reviewing RFCv0!

Patches high level description:

 o [01-02]/08 add the necessary links to start accounting DEADLINE contribution
              to OPP selection 
 o 03/08      it's a temporary solution to make possible (on ARM) to change
              frequency for DEADLINE tasks (that would possibly delay the SCHED_FIFO
              worker kthread); proper solution would be to be able to issue frequency
              transition from an atomic ctx
 o [04-05]/08 it's a schedutil change that copes with the fact that DEADLINE
              doesn't require periodic OPP selection triggering point
 o [06-07]/08 make arch_scale_{freq,cpu}_capacity() function available on !CONFIG_SMP
              configurations too
 o 08/08      implements frequency/cpu invariance for tasks' reservation
              parameters; which basically means that we implement GRUB-PA [2]

Changes w.r.t. RFCv0:

 - rebase on tip/sched/core
 - make use of BW_SHIFT for calculations (Peter)
 - added a comment about guaranteed/requested frequency (Peter)
 - use a high bit for sched_flags SCHED_FLAG_SPECIAL hack; don't expose it to
   userspace and add comments (Peter)
 - refactor aggregation of utilization from scheduling classes

Please have a look. Feedback and comments are, as usual, more than welcome.

In case you would like to test this out:

 git://linux-arm.org/linux-jl.git upstream/deadline/freq-rfc-v1

Best,

- Juri


Juri Lelli (8):
  sched/cpufreq_schedutil: make use of DEADLINE utilization signal
  sched/deadline: move cpu frequency selection triggering points
  sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE
  sched/cpufreq_schedutil: split utilization signals
  sched/cpufreq_schedutil: always consider all CPUs when deciding next
    freq
  sched/sched.h: remove sd arch_scale_freq_capacity parameter
  sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP
  sched/deadline: make bandwidth enforcement scale-invariant

 include/linux/sched.h            |  1 +
 include/linux/sched/cpufreq.h    |  2 --
 include/linux/sched/topology.h   | 12 +++----
 kernel/sched/core.c              | 15 ++++++--
 kernel/sched/cpufreq_schedutil.c | 77 ++++++++++++++++++++++++++--------------
 kernel/sched/deadline.c          | 46 ++++++++++++++++++++----
 kernel/sched/fair.c              |  4 +--
 kernel/sched/sched.h             | 51 +++++++++++++++++++-------
 8 files changed, 149 insertions(+), 59 deletions(-)

-- 
2.11.0

[toc] | [next] | [standalone]

#1681396 — [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

No assumption can be made upon the rate at which frequency updates get
triggered, as there are scheduling policies (like SCHED_DEADLINE) which
don't trigger them so frequently.

Remove such assumption from the code, by always considering
SCHED_DEADLINE utilization signal as not stale.

Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Luca Abeni <luca.abeni@santannapisa.it>
Cc: Claudio Scordino <claudio@evidence.eu.com>
---
 kernel/sched/cpufreq_schedutil.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index e835fa886225..066b876d81e7 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -267,17 +267,22 @@ static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time)
 		s64 delta_ns;
 
 		/*
-		 * If the CPU utilization was last updated before the previous
-		 * frequency update and the time elapsed between the last update
-		 * of the CPU utilization and the last frequency update is long
-		 * enough, don't take the CPU into account as it probably is
-		 * idle now (and clear iowait_boost for it).
+		 * If the CFS CPU utilization was last updated before the
+		 * previous frequency update and the time elapsed between the
+		 * last update of the CPU utilization and the last frequency
+		 * update is long enough, reset iowait_boost and util_cfs, as
+		 * they are now probably stale. However, still consider the
+		 * CPU contribution if it has some DEADLINE utilization
+		 * (util_dl).
 		 */
 		delta_ns = time - j_sg_cpu->last_update;
 		if (delta_ns > TICK_NSEC) {
 			j_sg_cpu->iowait_boost = 0;
-			continue;
+			j_sg_cpu->util_cfs = 0;
+			if (j_sg_cpu->util_dl == 0)
+				continue;
 		}
+
 		if (j_sg_cpu->flags & SCHED_CPUFREQ_RT)
 			return policy->cpuinfo.max_freq;
 
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1683038 — Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

On 05-07-17, 09:59, Juri Lelli wrote:
> No assumption can be made upon the rate at which frequency updates get
> triggered, as there are scheduling policies (like SCHED_DEADLINE) which
> don't trigger them so frequently.
> 
> Remove such assumption from the code, by always considering
> SCHED_DEADLINE utilization signal as not stale.
> 
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Luca Abeni <luca.abeni@santannapisa.it>
> Cc: Claudio Scordino <claudio@evidence.eu.com>
> ---
>  kernel/sched/cpufreq_schedutil.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index e835fa886225..066b876d81e7 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -267,17 +267,22 @@ static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time)
>  		s64 delta_ns;
>  
>  		/*
> -		 * If the CPU utilization was last updated before the previous
> -		 * frequency update and the time elapsed between the last update
> -		 * of the CPU utilization and the last frequency update is long
> -		 * enough, don't take the CPU into account as it probably is
> -		 * idle now (and clear iowait_boost for it).
> +		 * If the CFS CPU utilization was last updated before the
> +		 * previous frequency update and the time elapsed between the
> +		 * last update of the CPU utilization and the last frequency
> +		 * update is long enough, reset iowait_boost and util_cfs, as
> +		 * they are now probably stale. However, still consider the
> +		 * CPU contribution if it has some DEADLINE utilization
> +		 * (util_dl).
>  		 */
>  		delta_ns = time - j_sg_cpu->last_update;
>  		if (delta_ns > TICK_NSEC) {
>  			j_sg_cpu->iowait_boost = 0;
> -			continue;
> +			j_sg_cpu->util_cfs = 0;
> +			if (j_sg_cpu->util_dl == 0)
> +				continue;
>  		}
> +
>  		if (j_sg_cpu->flags & SCHED_CPUFREQ_RT)
>  			return policy->cpuinfo.max_freq;
>  

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1685185 — Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

On Wed, Jul 05, 2017 at 09:59:02AM +0100, Juri Lelli wrote:
>  		delta_ns = time - j_sg_cpu->last_update;
>  		if (delta_ns > TICK_NSEC) {
>  			j_sg_cpu->iowait_boost = 0;
> -			continue;
> +			j_sg_cpu->util_cfs = 0;

this is slighly confusing. Is this because we might not 'continue' with
the new code?

> +			if (j_sg_cpu->util_dl == 0)
> +				continue;
>  		}
> +
>  		if (j_sg_cpu->flags & SCHED_CPUFREQ_RT)
>  			return policy->cpuinfo.max_freq;
>  
> -- 
> 2.11.0
> 

[toc] | [prev] | [next] | [standalone]

#1685227 — Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

On 11/07/17 18:17, Peter Zijlstra wrote:
> On Wed, Jul 05, 2017 at 09:59:02AM +0100, Juri Lelli wrote:
> >  		delta_ns = time - j_sg_cpu->last_update;
> >  		if (delta_ns > TICK_NSEC) {
> >  			j_sg_cpu->iowait_boost = 0;
> > -			continue;
> > +			j_sg_cpu->util_cfs = 0;
> 
> this is slighly confusing. Is this because we might not 'continue' with
> the new code?
> 

This is because, after TICK_NSEC, we only want to discard CFS
contribution and (yes) continue (so don't take into account
j_sg_cpu contribution) if DEADLINE contribution is zero as well.

> > +			if (j_sg_cpu->util_dl == 0)
> > +				continue;
> >  		}
> > +

With this change we might not continue if some DEADLINE utilization is
present for j_sg_cpu.

> >  		if (j_sg_cpu->flags & SCHED_CPUFREQ_RT)
> >  			return policy->cpuinfo.max_freq;
> >  
> > -- 
> > 2.11.0
> > 

[toc] | [prev] | [next] | [standalone]

#1681398 — [RFC PATCH v1 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP

Currently, frequency and cpu capacity scaling is only performed on
CONFIG_SMP systems (as CFS PELT signals are only present for such
systems). However, other scheduling classes want to do freq/cpu scaling,
and for !CONFIG_SMP configurations as well.

arch_scale_freq_capacity is useful to implement frequency scaling even
on !CONFIG_SMP platforms, so we simply move it outside CONFIG_SMP
ifdeffery.

Even if arch_scale_cpu_capacity is not useful on !CONFIG_SMP platforms,
we make a default implementation available for such configurations anyway
to simplify scheduler code doing CPU scale invariance.

Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
---
 include/linux/sched/topology.h | 12 ++++++------
 kernel/sched/sched.h           | 13 ++++++++++---
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index 7d065abc7a47..953cf4f889ec 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -6,6 +6,12 @@
 #include <linux/sched/idle.h>
 
 /*
+ * Increase resolution of cpu_capacity calculations
+ */
+#define SCHED_CAPACITY_SHIFT	SCHED_FIXEDPOINT_SHIFT
+#define SCHED_CAPACITY_SCALE	(1L << SCHED_CAPACITY_SHIFT)
+
+/*
  * sched-domains (multiprocessor balancing) declarations:
  */
 #ifdef CONFIG_SMP
@@ -26,12 +32,6 @@
 #define SD_OVERLAP		0x2000	/* sched_domains of this level overlap */
 #define SD_NUMA			0x4000	/* cross-node balancing */
 
-/*
- * Increase resolution of cpu_capacity calculations
- */
-#define SCHED_CAPACITY_SHIFT	SCHED_FIXEDPOINT_SHIFT
-#define SCHED_CAPACITY_SCALE	(1L << SCHED_CAPACITY_SHIFT)
-
 #ifdef CONFIG_SCHED_SMT
 static inline int cpu_smt_flags(void)
 {
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index ec5769288927..178f4a5df2fa 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1668,9 +1668,6 @@ static inline int hrtick_enabled(struct rq *rq)
 
 #endif /* CONFIG_SCHED_HRTICK */
 
-#ifdef CONFIG_SMP
-extern void sched_avg_update(struct rq *rq);
-
 #ifndef arch_scale_freq_capacity
 static __always_inline
 unsigned long arch_scale_freq_capacity(int cpu)
@@ -1679,6 +1676,9 @@ unsigned long arch_scale_freq_capacity(int cpu)
 }
 #endif
 
+#ifdef CONFIG_SMP
+extern void sched_avg_update(struct rq *rq);
+
 #ifndef arch_scale_cpu_capacity
 static __always_inline
 unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
@@ -1696,6 +1696,13 @@ static inline void sched_rt_avg_update(struct rq *rq, u64 rt_delta)
 	sched_avg_update(rq);
 }
 #else
+#ifndef arch_scale_cpu_capacity
+static __always_inline
+unsigned long arch_scale_cpu_capacity(void __always_unused *sd, int cpu)
+{
+	return SCHED_CAPACITY_SCALE;
+}
+#endif
 static inline void sched_rt_avg_update(struct rq *rq, u64 rt_delta) { }
 static inline void sched_avg_update(struct rq *rq) { }
 #endif
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1683438 — Re: [RFC PATCH v1 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP

On Wed,  5 Jul 2017 09:59:04 +0100
Juri Lelli <juri.lelli@arm.com> wrote:

> Currently, frequency and cpu capacity scaling is only performed on
> CONFIG_SMP systems (as CFS PELT signals are only present for such
> systems). However, other scheduling classes want to do freq/cpu scaling,
> and for !CONFIG_SMP configurations as well.
> 
> arch_scale_freq_capacity is useful to implement frequency scaling even
> on !CONFIG_SMP platforms, so we simply move it outside CONFIG_SMP
> ifdeffery.
> 
> Even if arch_scale_cpu_capacity is not useful on !CONFIG_SMP platforms,
> we make a default implementation available for such configurations anyway
> to simplify scheduler code doing CPU scale invariance.
> 

Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> ---
>  include/linux/sched/topology.h | 12 ++++++------
>  kernel/sched/sched.h           | 13 ++++++++++---
>  2 files changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
> index 7d065abc7a47..953cf4f889ec 100644
> --- a/include/linux/sched/topology.h
> +++ b/include/linux/sched/topology.h
> @@ -6,6 +6,12 @@
>  #include <linux/sched/idle.h>
>  
>  /*
> + * Increase resolution of cpu_capacity calculations
> + */
> +#define SCHED_CAPACITY_SHIFT	SCHED_FIXEDPOINT_SHIFT
> +#define SCHED_CAPACITY_SCALE	(1L << SCHED_CAPACITY_SHIFT)
> +
> +/*
>   * sched-domains (multiprocessor balancing) declarations:
>   */
>  #ifdef CONFIG_SMP
> @@ -26,12 +32,6 @@
>  #define SD_OVERLAP		0x2000	/* sched_domains of this level overlap */
>  #define SD_NUMA			0x4000	/* cross-node balancing */
>  
> -/*
> - * Increase resolution of cpu_capacity calculations
> - */
> -#define SCHED_CAPACITY_SHIFT	SCHED_FIXEDPOINT_SHIFT
> -#define SCHED_CAPACITY_SCALE	(1L << SCHED_CAPACITY_SHIFT)
> -
>  #ifdef CONFIG_SCHED_SMT
>  static inline int cpu_smt_flags(void)
>  {
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index ec5769288927..178f4a5df2fa 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1668,9 +1668,6 @@ static inline int hrtick_enabled(struct rq *rq)
>  
>  #endif /* CONFIG_SCHED_HRTICK */
>  
> -#ifdef CONFIG_SMP
> -extern void sched_avg_update(struct rq *rq);
> -
>  #ifndef arch_scale_freq_capacity
>  static __always_inline
>  unsigned long arch_scale_freq_capacity(int cpu)
> @@ -1679,6 +1676,9 @@ unsigned long arch_scale_freq_capacity(int cpu)
>  }
>  #endif
>  
> +#ifdef CONFIG_SMP
> +extern void sched_avg_update(struct rq *rq);
> +
>  #ifndef arch_scale_cpu_capacity
>  static __always_inline
>  unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
> @@ -1696,6 +1696,13 @@ static inline void sched_rt_avg_update(struct rq *rq, u64 rt_delta)
>  	sched_avg_update(rq);
>  }
>  #else
> +#ifndef arch_scale_cpu_capacity
> +static __always_inline
> +unsigned long arch_scale_cpu_capacity(void __always_unused *sd, int cpu)
> +{
> +	return SCHED_CAPACITY_SCALE;
> +}
> +#endif
>  static inline void sched_rt_avg_update(struct rq *rq, u64 rt_delta) { }
>  static inline void sched_avg_update(struct rq *rq) { }
>  #endif

[toc] | [prev] | [next] | [standalone]

#1681400 — [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

To be able to treat utilization signals of different scheduling classes
in different ways (e.g., CFS signal might be stale while DEADLINE signal
is never stale by design) we need to split sugov_cpu::util signal in two:
util_cfs and util_dl.

This patch does that by also changing sugov_get_util() parameter list.
After this change, aggregation of the different signals has to be performed
by sugov_get_util() users (so that they can decide what to do with the
different signals).

Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Luca Abeni <luca.abeni@santannapisa.it>
Cc: Claudio Scordino <claudio@evidence.eu.com>
---
Changes from RFCv0:

 - refactor aggregation of utilization in sugov_aggregate_util()
---
 kernel/sched/cpufreq_schedutil.c | 28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index ba6227625f24..e835fa886225 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -58,7 +58,8 @@ struct sugov_cpu {
 	u64 last_update;
 
 	/* The fields below are only needed when sharing a policy. */
-	unsigned long util;
+	unsigned long util_cfs;
+	unsigned long util_dl;
 	unsigned long max;
 	unsigned int flags;
 
@@ -154,20 +155,24 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
 	return cpufreq_driver_resolve_freq(policy, freq);
 }
 
-static void sugov_get_util(unsigned long *util, unsigned long *max)
+static void sugov_get_util(struct sugov_cpu *sg_cpu)
 {
 	struct rq *rq = this_rq();
-	unsigned long dl_util = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
-				>> BW_SHIFT;
 
-	*max = arch_scale_cpu_capacity(NULL, smp_processor_id());
+	sg_cpu->max = arch_scale_cpu_capacity(NULL, smp_processor_id());
+	sg_cpu->util_cfs = rq->cfs.avg.util_avg;
+	sg_cpu->util_dl = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
+			  >> BW_SHIFT;
+}
 
+static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
+{
 	/*
 	 * Ideally we would like to set util_dl as min/guaranteed freq and
 	 * util_cfs + util_dl as requested freq. However, cpufreq is not yet
 	 * ready for such an interface. So, we only do the latter for now.
 	 */
-	*util = min(rq->cfs.avg.util_avg + dl_util, *max);
+	return min(sg_cpu->util_cfs + sg_cpu->util_dl, sg_cpu->max);
 }
 
 static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
@@ -234,7 +239,9 @@ static void sugov_update_single(struct update_util_data *hook, u64 time,
 	if (flags & SCHED_CPUFREQ_RT) {
 		next_f = policy->cpuinfo.max_freq;
 	} else {
-		sugov_get_util(&util, &max);
+		sugov_get_util(sg_cpu);
+		max = sg_cpu->max;
+		util = sugov_aggregate_util(sg_cpu);
 		sugov_iowait_boost(sg_cpu, &util, &max);
 		next_f = get_next_freq(sg_policy, util, max);
 		/*
@@ -274,8 +281,8 @@ static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time)
 		if (j_sg_cpu->flags & SCHED_CPUFREQ_RT)
 			return policy->cpuinfo.max_freq;
 
-		j_util = j_sg_cpu->util;
 		j_max = j_sg_cpu->max;
+		j_util = sugov_aggregate_util(j_sg_cpu);
 		if (j_util * max > j_max * util) {
 			util = j_util;
 			max = j_max;
@@ -292,15 +299,12 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time,
 {
 	struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_util);
 	struct sugov_policy *sg_policy = sg_cpu->sg_policy;
-	unsigned long util, max;
 	unsigned int next_f;
 
-	sugov_get_util(&util, &max);
 
 	raw_spin_lock(&sg_policy->update_lock);
 
-	sg_cpu->util = util;
-	sg_cpu->max = max;
+	sugov_get_util(sg_cpu);
 	sg_cpu->flags = flags;
 
 	sugov_set_iowait_boost(sg_cpu, time, flags);
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1682891 — Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

Hi Juri,

On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli <juri.lelli@arm.com> wrote:
> To be able to treat utilization signals of different scheduling classes
> in different ways (e.g., CFS signal might be stale while DEADLINE signal
> is never stale by design) we need to split sugov_cpu::util signal in two:
> util_cfs and util_dl.
>
> This patch does that by also changing sugov_get_util() parameter list.
> After this change, aggregation of the different signals has to be performed
> by sugov_get_util() users (so that they can decide what to do with the
> different signals).
>
> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Luca Abeni <luca.abeni@santannapisa.it>
> Cc: Claudio Scordino <claudio@evidence.eu.com>
> ---
> Changes from RFCv0:
>
>  - refactor aggregation of utilization in sugov_aggregate_util()
> ---
>  kernel/sched/cpufreq_schedutil.c | 28 ++++++++++++++++------------
>  1 file changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index ba6227625f24..e835fa886225 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -58,7 +58,8 @@ struct sugov_cpu {
>         u64 last_update;
>
>         /* The fields below are only needed when sharing a policy. */
> -       unsigned long util;
> +       unsigned long util_cfs;
> +       unsigned long util_dl;
>         unsigned long max;
>         unsigned int flags;
>
> @@ -154,20 +155,24 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
>         return cpufreq_driver_resolve_freq(policy, freq);
>  }
>
> -static void sugov_get_util(unsigned long *util, unsigned long *max)
> +static void sugov_get_util(struct sugov_cpu *sg_cpu)
>  {
>         struct rq *rq = this_rq();
> -       unsigned long dl_util = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
> -                               >> BW_SHIFT;
>
> -       *max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> +       sg_cpu->max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> +       sg_cpu->util_cfs = rq->cfs.avg.util_avg;
> +       sg_cpu->util_dl = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
> +                         >> BW_SHIFT;
> +}
>
> +static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> +{
>         /*
>          * Ideally we would like to set util_dl as min/guaranteed freq and
>          * util_cfs + util_dl as requested freq. However, cpufreq is not yet
>          * ready for such an interface. So, we only do the latter for now.
>          */
> -       *util = min(rq->cfs.avg.util_avg + dl_util, *max);
> +       return min(sg_cpu->util_cfs + sg_cpu->util_dl, sg_cpu->max);
>  }

I am wondering why the need for a separate aggregation API. To me, it
looks like using sugov_get_util to set the sg_cpu util elements and
then do the aggregation at the same time would have the same effect
(without changing the existing parameter list). Is this to handle a
future usecase where aggregation may need to be done differently? For
all the user's of sugov_get_util, aggregation is done in the same way.
Anyway if I missed something, sorry for the noise.

thanks,

-Joel

[toc] | [prev] | [next] | [standalone]

#1683041 — Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

On 05-07-17, 09:59, Juri Lelli wrote:
> To be able to treat utilization signals of different scheduling classes
> in different ways (e.g., CFS signal might be stale while DEADLINE signal
> is never stale by design) we need to split sugov_cpu::util signal in two:
> util_cfs and util_dl.
> 
> This patch does that by also changing sugov_get_util() parameter list.
> After this change, aggregation of the different signals has to be performed
> by sugov_get_util() users (so that they can decide what to do with the
> different signals).
> 
> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Are you referring to this response here ?

https://marc.info/?l=linux-kernel&m=149095102600847&w=2

If yes, then I don't think it was about having separate APIs, but just storing
util_cfs/dl separately.

> -static void sugov_get_util(unsigned long *util, unsigned long *max)
> +static void sugov_get_util(struct sugov_cpu *sg_cpu)
>  {
>  	struct rq *rq = this_rq();
> -	unsigned long dl_util = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
> -				>> BW_SHIFT;
>  
> -	*max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> +	sg_cpu->max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> +	sg_cpu->util_cfs = rq->cfs.avg.util_avg;
> +	sg_cpu->util_dl = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
> +			  >> BW_SHIFT;
> +}
>  
> +static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)

As Joel already mentioned, I don't think we should create two separate routines
here.

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1683124 — Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

Hi,

On 07/07/17 14:28, Viresh Kumar wrote:
> On 05-07-17, 09:59, Juri Lelli wrote:
> > To be able to treat utilization signals of different scheduling classes
> > in different ways (e.g., CFS signal might be stale while DEADLINE signal
> > is never stale by design) we need to split sugov_cpu::util signal in two:
> > util_cfs and util_dl.
> > 
> > This patch does that by also changing sugov_get_util() parameter list.
> > After this change, aggregation of the different signals has to be performed
> > by sugov_get_util() users (so that they can decide what to do with the
> > different signals).
> > 
> > Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Are you referring to this response here ?
> 
> https://marc.info/?l=linux-kernel&m=149095102600847&w=2
> 

Yep.

> If yes, then I don't think it was about having separate APIs, but just storing
> util_cfs/dl separately.
> 
> > -static void sugov_get_util(unsigned long *util, unsigned long *max)
> > +static void sugov_get_util(struct sugov_cpu *sg_cpu)
> >  {
> >  	struct rq *rq = this_rq();
> > -	unsigned long dl_util = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
> > -				>> BW_SHIFT;
> >  
> > -	*max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> > +	sg_cpu->max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> > +	sg_cpu->util_cfs = rq->cfs.avg.util_avg;
> > +	sg_cpu->util_dl = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
> > +			  >> BW_SHIFT;
> > +}
> >  
> > +static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> 
> As Joel already mentioned, I don't think we should create two separate routines
> here.
> 

Mmm, it makes retrieving of utilization in sugov_update_shared and
aggregating values for the domain in sugov_next_freq_shared cleaner,
IMHO.

Thanks,

- Juri

[toc] | [prev] | [next] | [standalone]

#1684016 — Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

On Fri, Jul 7, 2017 at 3:59 AM, Juri Lelli <juri.lelli@arm.com> wrote:
[..]
>
>> If yes, then I don't think it was about having separate APIs, but just storing
>> util_cfs/dl separately.
>>
>> > -static void sugov_get_util(unsigned long *util, unsigned long *max)
>> > +static void sugov_get_util(struct sugov_cpu *sg_cpu)
>> >  {
>> >     struct rq *rq = this_rq();
>> > -   unsigned long dl_util = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
>> > -                           >> BW_SHIFT;
>> >
>> > -   *max = arch_scale_cpu_capacity(NULL, smp_processor_id());
>> > +   sg_cpu->max = arch_scale_cpu_capacity(NULL, smp_processor_id());
>> > +   sg_cpu->util_cfs = rq->cfs.avg.util_avg;
>> > +   sg_cpu->util_dl = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
>> > +                     >> BW_SHIFT;
>> > +}
>> >
>> > +static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
>>
>> As Joel already mentioned, I don't think we should create two separate routines
>> here.
>>
>
> Mmm, it makes retrieving of utilization in sugov_update_shared and
> aggregating values for the domain in sugov_next_freq_shared cleaner,
> IMHO.
>

I agree, thanks.

-Joel

[toc] | [prev] | [next] | [standalone]

#1684005 — Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

On 05-07-17, 09:59, Juri Lelli wrote:
> To be able to treat utilization signals of different scheduling classes
> in different ways (e.g., CFS signal might be stale while DEADLINE signal
> is never stale by design) we need to split sugov_cpu::util signal in two:
> util_cfs and util_dl.
> 
> This patch does that by also changing sugov_get_util() parameter list.
> After this change, aggregation of the different signals has to be performed
> by sugov_get_util() users (so that they can decide what to do with the
> different signals).
> 
> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Luca Abeni <luca.abeni@santannapisa.it>
> Cc: Claudio Scordino <claudio@evidence.eu.com>
> ---
> Changes from RFCv0:
> 
>  - refactor aggregation of utilization in sugov_aggregate_util()
> ---
>  kernel/sched/cpufreq_schedutil.c | 28 ++++++++++++++++------------
>  1 file changed, 16 insertions(+), 12 deletions(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1681401 — [RFC PATCH v1 2/8] sched/deadline: move cpu frequency selection triggering points

Since SCHED_DEADLINE doesn't track utilization signal (but reserves a
fraction of CPU bandwidth to tasks admitted to the system), there is no
point in evaluating frequency changes during each tick event.

Move frequency selection triggering points to where running_bw changes.

Co-authored-by: Claudio Scordino <claudio@evidence.eu.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Luca Abeni <luca.abeni@santannapisa.it>
---
Changes from RFCv0:

 - modify comment regarding periodic RT updates (Claudio)
---
 kernel/sched/deadline.c |  7 ++++---
 kernel/sched/sched.h    | 12 ++++++------
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a84299f44b5d..6912f7f35f9b 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -85,6 +85,8 @@ void add_running_bw(u64 dl_bw, struct dl_rq *dl_rq)
 	dl_rq->running_bw += dl_bw;
 	SCHED_WARN_ON(dl_rq->running_bw < old); /* overflow */
 	SCHED_WARN_ON(dl_rq->running_bw > dl_rq->this_bw);
+	/* kick cpufreq (see the comment in kernel/sched/sched.h). */
+	cpufreq_update_this_cpu(rq_of_dl_rq(dl_rq), SCHED_CPUFREQ_DL);
 }
 
 static inline
@@ -97,6 +99,8 @@ void sub_running_bw(u64 dl_bw, struct dl_rq *dl_rq)
 	SCHED_WARN_ON(dl_rq->running_bw > old); /* underflow */
 	if (dl_rq->running_bw > old)
 		dl_rq->running_bw = 0;
+	/* kick cpufreq (see the comment in kernel/sched/sched.h). */
+	cpufreq_update_this_cpu(rq_of_dl_rq(dl_rq), SCHED_CPUFREQ_DL);
 }
 
 static inline
@@ -1135,9 +1139,6 @@ static void update_curr_dl(struct rq *rq)
 		return;
 	}
 
-	/* kick cpufreq (see the comment in kernel/sched/sched.h). */
-	cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_DL);
-
 	schedstat_set(curr->se.statistics.exec_max,
 		      max(curr->se.statistics.exec_max, delta_exec));
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index eeef1a3086d1..d8798bb54ace 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2057,14 +2057,14 @@ DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
  * The way cpufreq is currently arranged requires it to evaluate the CPU
  * performance state (frequency/voltage) on a regular basis to prevent it from
  * being stuck in a completely inadequate performance level for too long.
- * That is not guaranteed to happen if the updates are only triggered from CFS,
- * though, because they may not be coming in if RT or deadline tasks are active
- * all the time (or there are RT and DL tasks only).
+ * That is not guaranteed to happen if the updates are only triggered from CFS
+ * and DL, though, because they may not be coming in if only RT tasks are
+ * active all the time (or there are RT tasks only).
  *
- * As a workaround for that issue, this function is called by the RT and DL
- * sched classes to trigger extra cpufreq updates to prevent it from stalling,
+ * As a workaround for that issue, this function is called periodically by the
+ * RT sched class to trigger extra cpufreq updates to prevent it from stalling,
  * but that really is a band-aid.  Going forward it should be replaced with
- * solutions targeted more specifically at RT and DL tasks.
+ * solutions targeted more specifically at RT tasks.
  */
 static inline void cpufreq_update_util(struct rq *rq, unsigned int flags)
 {
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1682984 — Re: [RFC PATCH v1 2/8] sched/deadline: move cpu frequency selection triggering points

On 05-07-17, 09:58, Juri Lelli wrote:
> Since SCHED_DEADLINE doesn't track utilization signal (but reserves a
> fraction of CPU bandwidth to tasks admitted to the system), there is no
> point in evaluating frequency changes during each tick event.
> 
> Move frequency selection triggering points to where running_bw changes.
> 
> Co-authored-by: Claudio Scordino <claudio@evidence.eu.com>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Luca Abeni <luca.abeni@santannapisa.it>
> ---
> Changes from RFCv0:
> 
>  - modify comment regarding periodic RT updates (Claudio)
> ---
>  kernel/sched/deadline.c |  7 ++++---
>  kernel/sched/sched.h    | 12 ++++++------
>  2 files changed, 10 insertions(+), 9 deletions(-)

Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1682532 — Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

On Wed,  5 Jul 2017 09:58:57 +0100
Juri Lelli <juri.lelli@arm.com> wrote:

> Hi,
> 
> v1 of the RFC set implementing frequency/cpu invariance and OPP selection for

It would be nice if you specify what "OPP" stands for. A quick google
search shows "Other Peoples Privates", which isn't the type of
selection I would be looking for.

-- Steve


> SCHED_DEADLINE [1]. The set is based on tip/sched/core as of today
> (72298e5c92c5), which now already includes Luca's "CPU reclaiming for
> SCHED_DEADLINE".
>

[toc] | [prev] | [next] | [standalone]

#1682545 — Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

On 06/07/17 11:57, Steven Rostedt wrote:
> On Wed,  5 Jul 2017 09:58:57 +0100
> Juri Lelli <juri.lelli@arm.com> wrote:
> 
> > Hi,
> > 
> > v1 of the RFC set implementing frequency/cpu invariance and OPP selection for
> 
> It would be nice if you specify what "OPP" stands for. A quick google
> search shows "Other Peoples Privates", which isn't the type of
> selection I would be looking for.
> 

Not something we could influence from the scheduler anyway. :)

Just to clarify, OPP in this context stands for "Operating Performance
Point": (frequency, voltage) tuple [1], used in this context as a
synonym of clock frequency.

I'll add in next version.

Thanks,

- Juri

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CHDGICAJ.html

[toc] | [prev] | [next] | [standalone]

#1682550 — Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

On Thu, Jul 06, 2017 at 11:57:15AM -0400, Steven Rostedt wrote:
> On Wed,  5 Jul 2017 09:58:57 +0100
> Juri Lelli <juri.lelli@arm.com> wrote:
> 
> > Hi,
> > 
> > v1 of the RFC set implementing frequency/cpu invariance and OPP selection for
> 
> It would be nice if you specify what "OPP" stands for. A quick google
> search shows "Other Peoples Privates", which isn't the type of
> selection I would be looking for.

Its ARM speak for P-state. It stands for OPerating Point or something
like that. But yes, I too always play the Naughty by Nature song in my
head when I read that.

[toc] | [prev] | [next] | [standalone]

#1682717

On Wednesday, July 05, 2017 09:58:57 AM Juri Lelli wrote:
> Hi,
> 
> v1 of the RFC set implementing frequency/cpu invariance and OPP selection for
> SCHED_DEADLINE [1]. The set is based on tip/sched/core as of today
> (72298e5c92c5), which now already includes Luca's "CPU reclaiming for
> SCHED_DEADLINE".
> 
> Thanks a lot for reviewing RFCv0!
> 
> Patches high level description:
> 
>  o [01-02]/08 add the necessary links to start accounting DEADLINE contribution
>               to OPP selection 
>  o 03/08      it's a temporary solution to make possible (on ARM) to change
>               frequency for DEADLINE tasks (that would possibly delay the SCHED_FIFO
>               worker kthread); proper solution would be to be able to issue frequency
>               transition from an atomic ctx
>  o [04-05]/08 it's a schedutil change that copes with the fact that DEADLINE
>               doesn't require periodic OPP selection triggering point
>  o [06-07]/08 make arch_scale_{freq,cpu}_capacity() function available on !CONFIG_SMP
>               configurations too
>  o 08/08      implements frequency/cpu invariance for tasks' reservation
>               parameters; which basically means that we implement GRUB-PA [2]
> 
> Changes w.r.t. RFCv0:
> 
>  - rebase on tip/sched/core
>  - make use of BW_SHIFT for calculations (Peter)
>  - added a comment about guaranteed/requested frequency (Peter)
>  - use a high bit for sched_flags SCHED_FLAG_SPECIAL hack; don't expose it to
>    userspace and add comments (Peter)
>  - refactor aggregation of utilization from scheduling classes
> 
> Please have a look. Feedback and comments are, as usual, more than welcome.
> 
> In case you would like to test this out:
> 
>  git://linux-arm.org/linux-jl.git upstream/deadline/freq-rfc-v1
> 
> Best,
> 
> - Juri
> 
> 
> Juri Lelli (8):
>   sched/cpufreq_schedutil: make use of DEADLINE utilization signal
>   sched/deadline: move cpu frequency selection triggering points
>   sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE
>   sched/cpufreq_schedutil: split utilization signals
>   sched/cpufreq_schedutil: always consider all CPUs when deciding next
>     freq
>   sched/sched.h: remove sd arch_scale_freq_capacity parameter
>   sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP
>   sched/deadline: make bandwidth enforcement scale-invariant
> 
>  include/linux/sched.h            |  1 +
>  include/linux/sched/cpufreq.h    |  2 --
>  include/linux/sched/topology.h   | 12 +++----
>  kernel/sched/core.c              | 15 ++++++--
>  kernel/sched/cpufreq_schedutil.c | 77 ++++++++++++++++++++++++++--------------
>  kernel/sched/deadline.c          | 46 ++++++++++++++++++++----
>  kernel/sched/fair.c              |  4 +--
>  kernel/sched/sched.h             | 51 +++++++++++++++++++-------
>  8 files changed, 149 insertions(+), 59 deletions(-)

The schedutil changes in this series look OK to me, so please feel free to add

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

to these patches.

Thanks,
Rafael

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web