mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH 0/4 v4] sched/rt: track rt rq utilization
@ 2018-03-16 11:25 Vincent Guittot
  2018-03-16 11:25 ` [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
                   ` (5 more replies)
  0 siblings, 6 replies; 15+ messages in thread
From: Vincent Guittot @ 2018-03-16 11:25 UTC (permalink / raw)
  To: peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, dietmar.eggemann, Morten.Rasmussen, viresh.kumar,
	valentin.schneider, Vincent Guittot

When both cfs and rt tasks compete to run on a CPU, we can see some frequency
drops with schedutil governor. In such case, the cfs_rq's utilization doesn't
reflect anymore the utilization of cfs tasks but only the remaining part that
is not used by rt tasks. We should monitor the stolen utilization and take
it into account when selecting OPP. This patchset doesn't change the OPP
selection policy for RT tasks but only for CFS tasks

A rt-app use case which creates an always running cfs thread and a rt threads
that wakes up periodically with both threads pinned on same CPU, show lot of 
frequency switches of the CPU whereas the CPU never goes idles during the 
test. I can share the json file that I used for the test if someone is
interested in.

For a 15 seconds long test on a hikey 6220 (octo core cortex A53 platfrom),
the cpufreq statistics outputs (stats are reset just before the test) : 
$ cat /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans
without patchset : 1230
with patchset : 14

If we replace the cfs thread of rt-app by a sysbench cpu test, we can see
performance improvements:

- Without patchset :
Test execution summary:
    total time:                          15.0009s
    total number of events:              4903
    total time taken by event execution: 14.9972
    per-request statistics:
         min:                                  1.23ms
         avg:                                  3.06ms
         max:                                 13.16ms
         approx.  95 percentile:              12.73ms

Threads fairness:
    events (avg/stddev):           4903.0000/0.00
    execution time (avg/stddev):   14.9972/0.00

- With patchset:
Test execution summary:
    total time:                          15.0014s
    total number of events:              7694
    total time taken by event execution: 14.9979
    per-request statistics:
         min:                                  1.23ms
         avg:                                  1.95ms
         max:                                 10.49ms
         approx.  95 percentile:              10.39ms

Threads fairness:
    events (avg/stddev):           7694.0000/0.00
    execution time (avg/stddev):   14.9979/0.00

The performance improvement is 56% for this use case.

Patch 1 move pelt code in pelt.c file
Patch 2 tracks utilization of rt_rq.
Patch 3 adds the rt_rq's utilization when selection OPP for cfs tasks
Patch 4 support periodic update of blocked rt utilization

Change since v3:
- add support of periodic update of blocked utilization
- rebase on lastest tip/sched/core

Change since v2:
- move pelt code into a dedicated pelt.c file
- rebase on load tracking changes

Change since v1:
- Only a rebase. I have addressed the comments on previous version in
  patch 1/2

Vincent Guittot (4):
  sched/pelt: Move pelt related code in a dedicated file
  sched/rt: add rt_rq utilization tracking
  cpufreq/schedutil: add rt utilization tracking
  sched/nohz: monitor rt utilization

 kernel/sched/Makefile            |   2 +-
 kernel/sched/cpufreq_schedutil.c |   4 +-
 kernel/sched/fair.c              | 321 ++-----------------------------------
 kernel/sched/pelt.c              | 331 +++++++++++++++++++++++++++++++++++++++
 kernel/sched/pelt.h              |  24 +++
 kernel/sched/rt.c                |   8 +
 kernel/sched/sched.h             |  28 ++++
 7 files changed, 410 insertions(+), 308 deletions(-)
 create mode 100644 kernel/sched/pelt.c
 create mode 100644 kernel/sched/pelt.h

-- 
2.7.4

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file
  2018-03-16 11:25 [PATCH 0/4 v4] sched/rt: track rt rq utilization Vincent Guittot
@ 2018-03-16 11:25 ` Vincent Guittot
  2018-04-15 11:58   ` Dietmar Eggemann
  2018-04-15 11:58   ` Dietmar Eggemann
  2018-03-16 11:25 ` [PATCH 2/4 v4] sched/rt: add rt_rq utilization tracking Vincent Guittot
                   ` (4 subsequent siblings)
  5 siblings, 2 replies; 15+ messages in thread
From: Vincent Guittot @ 2018-03-16 11:25 UTC (permalink / raw)
  To: peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, dietmar.eggemann, Morten.Rasmussen, viresh.kumar,
	valentin.schneider, Vincent Guittot

We want to track rt_rq's utilization as a part of the estimation of the
whole rq's utilization. This is necessary because rt tasks can steal
utilization to cfs tasks and make them lighter than they are.
As we want to use the same load tracking mecanism for both and prevent
useless dependency between cfs and rt code, pelt code is moved in a
dedicated file.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/Makefile |   2 +-
 kernel/sched/fair.c   | 306 +------------------------------------------------
 kernel/sched/pelt.c   | 308 ++++++++++++++++++++++++++++++++++++++++++++++++++
 kernel/sched/pelt.h   |  17 +++
 kernel/sched/sched.h  |  19 ++++
 5 files changed, 346 insertions(+), 306 deletions(-)
 create mode 100644 kernel/sched/pelt.c
 create mode 100644 kernel/sched/pelt.h

diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index d9a02b3..7fe1834 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -20,7 +20,7 @@ obj-y += core.o loadavg.o clock.o cputime.o
 obj-y += idle.o fair.o rt.o deadline.o
 obj-y += wait.o wait_bit.o swait.o completion.o
 
-obj-$(CONFIG_SMP) += cpupri.o cpudeadline.o topology.o stop_task.o
+obj-$(CONFIG_SMP) += cpupri.o cpudeadline.o topology.o stop_task.o pelt.o
 obj-$(CONFIG_SCHED_AUTOGROUP) += autogroup.o
 obj-$(CONFIG_SCHEDSTATS) += stats.o
 obj-$(CONFIG_SCHED_DEBUG) += debug.o
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3582117..bfd56bc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -255,9 +255,6 @@ static inline struct rq *rq_of(struct cfs_rq *cfs_rq)
 	return cfs_rq->rq;
 }
 
-/* An entity is a task if it doesn't "own" a runqueue */
-#define entity_is_task(se)	(!se->my_q)
-
 static inline struct task_struct *task_of(struct sched_entity *se)
 {
 	SCHED_WARN_ON(!entity_is_task(se));
@@ -419,7 +416,6 @@ static inline struct rq *rq_of(struct cfs_rq *cfs_rq)
 	return container_of(cfs_rq, struct rq, cfs);
 }
 
-#define entity_is_task(se)	1
 
 #define for_each_sched_entity(se) \
 		for (; se; se = NULL)
@@ -692,7 +688,7 @@ static u64 sched_vslice(struct cfs_rq *cfs_rq, struct sched_entity *se)
 }
 
 #ifdef CONFIG_SMP
-
+#include "pelt.h"
 #include "sched-pelt.h"
 
 static int select_idle_sibling(struct task_struct *p, int prev_cpu, int cpu);
@@ -2720,19 +2716,6 @@ account_entity_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se)
 } while (0)
 
 #ifdef CONFIG_SMP
-/*
- * XXX we want to get rid of these helpers and use the full load resolution.
- */
-static inline long se_weight(struct sched_entity *se)
-{
-	return scale_load_down(se->load.weight);
-}
-
-static inline long se_runnable(struct sched_entity *se)
-{
-	return scale_load_down(se->runnable_weight);
-}
-
 static inline void
 enqueue_runnable_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
@@ -3033,287 +3016,6 @@ static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq, int flags)
 }
 
 #ifdef CONFIG_SMP
-/*
- * Approximate:
- *   val * y^n,    where y^32 ~= 0.5 (~1 scheduling period)
- */
-static u64 decay_load(u64 val, u64 n)
-{
-	unsigned int local_n;
-
-	if (unlikely(n > LOAD_AVG_PERIOD * 63))
-		return 0;
-
-	/* after bounds checking we can collapse to 32-bit */
-	local_n = n;
-
-	/*
-	 * As y^PERIOD = 1/2, we can combine
-	 *    y^n = 1/2^(n/PERIOD) * y^(n%PERIOD)
-	 * With a look-up table which covers y^n (n<PERIOD)
-	 *
-	 * To achieve constant time decay_load.
-	 */
-	if (unlikely(local_n >= LOAD_AVG_PERIOD)) {
-		val >>= local_n / LOAD_AVG_PERIOD;
-		local_n %= LOAD_AVG_PERIOD;
-	}
-
-	val = mul_u64_u32_shr(val, runnable_avg_yN_inv[local_n], 32);
-	return val;
-}
-
-static u32 __accumulate_pelt_segments(u64 periods, u32 d1, u32 d3)
-{
-	u32 c1, c2, c3 = d3; /* y^0 == 1 */
-
-	/*
-	 * c1 = d1 y^p
-	 */
-	c1 = decay_load((u64)d1, periods);
-
-	/*
-	 *            p-1
-	 * c2 = 1024 \Sum y^n
-	 *            n=1
-	 *
-	 *              inf        inf
-	 *    = 1024 ( \Sum y^n - \Sum y^n - y^0 )
-	 *              n=0        n=p
-	 */
-	c2 = LOAD_AVG_MAX - decay_load(LOAD_AVG_MAX, periods) - 1024;
-
-	return c1 + c2 + c3;
-}
-
-/*
- * Accumulate the three separate parts of the sum; d1 the remainder
- * of the last (incomplete) period, d2 the span of full periods and d3
- * the remainder of the (incomplete) current period.
- *
- *           d1          d2           d3
- *           ^           ^            ^
- *           |           |            |
- *         |<->|<----------------->|<--->|
- * ... |---x---|------| ... |------|-----x (now)
- *
- *                           p-1
- * u' = (u + d1) y^p + 1024 \Sum y^n + d3 y^0
- *                           n=1
- *
- *    = u y^p +					(Step 1)
- *
- *                     p-1
- *      d1 y^p + 1024 \Sum y^n + d3 y^0		(Step 2)
- *                     n=1
- */
-static __always_inline u32
-accumulate_sum(u64 delta, int cpu, struct sched_avg *sa,
-	       unsigned long load, unsigned long runnable, int running)
-{
-	unsigned long scale_freq, scale_cpu;
-	u32 contrib = (u32)delta; /* p == 0 -> delta < 1024 */
-	u64 periods;
-
-	scale_freq = arch_scale_freq_capacity(cpu);
-	scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
-
-	delta += sa->period_contrib;
-	periods = delta / 1024; /* A period is 1024us (~1ms) */
-
-	/*
-	 * Step 1: decay old *_sum if we crossed period boundaries.
-	 */
-	if (periods) {
-		sa->load_sum = decay_load(sa->load_sum, periods);
-		sa->runnable_load_sum =
-			decay_load(sa->runnable_load_sum, periods);
-		sa->util_sum = decay_load((u64)(sa->util_sum), periods);
-
-		/*
-		 * Step 2
-		 */
-		delta %= 1024;
-		contrib = __accumulate_pelt_segments(periods,
-				1024 - sa->period_contrib, delta);
-	}
-	sa->period_contrib = delta;
-
-	contrib = cap_scale(contrib, scale_freq);
-	if (load)
-		sa->load_sum += load * contrib;
-	if (runnable)
-		sa->runnable_load_sum += runnable * contrib;
-	if (running)
-		sa->util_sum += contrib * scale_cpu;
-
-	return periods;
-}
-
-/*
- * We can represent the historical contribution to runnable average as the
- * coefficients of a geometric series.  To do this we sub-divide our runnable
- * history into segments of approximately 1ms (1024us); label the segment that
- * occurred N-ms ago p_N, with p_0 corresponding to the current period, e.g.
- *
- * [<- 1024us ->|<- 1024us ->|<- 1024us ->| ...
- *      p0            p1           p2
- *     (now)       (~1ms ago)  (~2ms ago)
- *
- * Let u_i denote the fraction of p_i that the entity was runnable.
- *
- * We then designate the fractions u_i as our co-efficients, yielding the
- * following representation of historical load:
- *   u_0 + u_1*y + u_2*y^2 + u_3*y^3 + ...
- *
- * We choose y based on the with of a reasonably scheduling period, fixing:
- *   y^32 = 0.5
- *
- * This means that the contribution to load ~32ms ago (u_32) will be weighted
- * approximately half as much as the contribution to load within the last ms
- * (u_0).
- *
- * When a period "rolls over" and we have new u_0`, multiplying the previous
- * sum again by y is sufficient to update:
- *   load_avg = u_0` + y*(u_0 + u_1*y + u_2*y^2 + ... )
- *            = u_0 + u_1*y + u_2*y^2 + ... [re-labeling u_i --> u_{i+1}]
- */
-static __always_inline int
-___update_load_sum(u64 now, int cpu, struct sched_avg *sa,
-		  unsigned long load, unsigned long runnable, int running)
-{
-	u64 delta;
-
-	delta = now - sa->last_update_time;
-	/*
-	 * This should only happen when time goes backwards, which it
-	 * unfortunately does during sched clock init when we swap over to TSC.
-	 */
-	if ((s64)delta < 0) {
-		sa->last_update_time = now;
-		return 0;
-	}
-
-	/*
-	 * Use 1024ns as the unit of measurement since it's a reasonable
-	 * approximation of 1us and fast to compute.
-	 */
-	delta >>= 10;
-	if (!delta)
-		return 0;
-
-	sa->last_update_time += delta << 10;
-
-	/*
-	 * running is a subset of runnable (weight) so running can't be set if
-	 * runnable is clear. But there are some corner cases where the current
-	 * se has been already dequeued but cfs_rq->curr still points to it.
-	 * This means that weight will be 0 but not running for a sched_entity
-	 * but also for a cfs_rq if the latter becomes idle. As an example,
-	 * this happens during idle_balance() which calls
-	 * update_blocked_averages()
-	 */
-	if (!load)
-		runnable = running = 0;
-
-	/*
-	 * Now we know we crossed measurement unit boundaries. The *_avg
-	 * accrues by two steps:
-	 *
-	 * Step 1: accumulate *_sum since last_update_time. If we haven't
-	 * crossed period boundaries, finish.
-	 */
-	if (!accumulate_sum(delta, cpu, sa, load, runnable, running))
-		return 0;
-
-	return 1;
-}
-
-static __always_inline void
-___update_load_avg(struct sched_avg *sa, unsigned long load, unsigned long runnable)
-{
-	u32 divider = LOAD_AVG_MAX - 1024 + sa->period_contrib;
-
-	/*
-	 * Step 2: update *_avg.
-	 */
-	sa->load_avg = div_u64(load * sa->load_sum, divider);
-	sa->runnable_load_avg =	div_u64(runnable * sa->runnable_load_sum, divider);
-	sa->util_avg = sa->util_sum / divider;
-}
-
-/*
- * sched_entity:
- *
- *   task:
- *     se_runnable() == se_weight()
- *
- *   group: [ see update_cfs_group() ]
- *     se_weight()   = tg->weight * grq->load_avg / tg->load_avg
- *     se_runnable() = se_weight(se) * grq->runnable_load_avg / grq->load_avg
- *
- *   load_sum := runnable_sum
- *   load_avg = se_weight(se) * runnable_avg
- *
- *   runnable_load_sum := runnable_sum
- *   runnable_load_avg = se_runnable(se) * runnable_avg
- *
- * XXX collapse load_sum and runnable_load_sum
- *
- * cfq_rs:
- *
- *   load_sum = \Sum se_weight(se) * se->avg.load_sum
- *   load_avg = \Sum se->avg.load_avg
- *
- *   runnable_load_sum = \Sum se_runnable(se) * se->avg.runnable_load_sum
- *   runnable_load_avg = \Sum se->avg.runable_load_avg
- */
-
-static int
-__update_load_avg_blocked_se(u64 now, int cpu, struct sched_entity *se)
-{
-	if (entity_is_task(se))
-		se->runnable_weight = se->load.weight;
-
-	if (___update_load_sum(now, cpu, &se->avg, 0, 0, 0)) {
-		___update_load_avg(&se->avg, se_weight(se), se_runnable(se));
-		return 1;
-	}
-
-	return 0;
-}
-
-static int
-__update_load_avg_se(u64 now, int cpu, struct cfs_rq *cfs_rq, struct sched_entity *se)
-{
-	if (entity_is_task(se))
-		se->runnable_weight = se->load.weight;
-
-	if (___update_load_sum(now, cpu, &se->avg, !!se->on_rq, !!se->on_rq,
-				cfs_rq->curr == se)) {
-
-		___update_load_avg(&se->avg, se_weight(se), se_runnable(se));
-		return 1;
-	}
-
-	return 0;
-}
-
-static int
-__update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq)
-{
-	if (___update_load_sum(now, cpu, &cfs_rq->avg,
-				scale_load_down(cfs_rq->load.weight),
-				scale_load_down(cfs_rq->runnable_weight),
-				cfs_rq->curr != NULL)) {
-
-		___update_load_avg(&cfs_rq->avg, 1, 1);
-		return 1;
-	}
-
-	return 0;
-}
-
 #ifdef CONFIG_FAIR_GROUP_SCHED
 /**
  * update_tg_load_avg - update the tg's load avg
@@ -3875,12 +3577,6 @@ static int idle_balance(struct rq *this_rq, struct rq_flags *rf);
 
 #else /* CONFIG_SMP */
 
-static inline int
-update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
-{
-	return 0;
-}
-
 #define UPDATE_TG	0x0
 #define SKIP_AGE_LOAD	0x0
 #define DO_ATTACH	0x0
diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
new file mode 100644
index 0000000..d693e5e
--- /dev/null
+++ b/kernel/sched/pelt.c
@@ -0,0 +1,308 @@
+/*
+ * Per Entity Load Tracking
+ *
+ *  Copyright (C) 2007 Red Hat, Inc., Ingo Molnar <mingo@redhat.com>
+ *
+ *  Interactivity improvements by Mike Galbraith
+ *  (C) 2007 Mike Galbraith <efault@gmx.de>
+ *
+ *  Various enhancements by Dmitry Adamushko.
+ *  (C) 2007 Dmitry Adamushko <dmitry.adamushko@gmail.com>
+ *
+ *  Group scheduling enhancements by Srivatsa Vaddagiri
+ *  Copyright IBM Corporation, 2007
+ *  Author: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
+ *
+ *  Scaled math optimizations by Thomas Gleixner
+ *  Copyright (C) 2007, Thomas Gleixner <tglx@linutronix.de>
+ *
+ *  Adaptive scheduling granularity, math enhancements by Peter Zijlstra
+ *  Copyright (C) 2007 Red Hat, Inc., Peter Zijlstra
+ *
+ *  Move PELT related code from fair.c into this pelt.c file
+ *  Author: Vincent Guittot <vincent.guittot@linaro.org>
+ */
+
+#include <linux/sched.h>
+#include "sched.h"
+#include "sched-pelt.h"
+
+/*
+ * Approximate:
+ *   val * y^n,    where y^32 ~= 0.5 (~1 scheduling period)
+ */
+static u64 decay_load(u64 val, u64 n)
+{
+	unsigned int local_n;
+
+	if (unlikely(n > LOAD_AVG_PERIOD * 63))
+		return 0;
+
+	/* after bounds checking we can collapse to 32-bit */
+	local_n = n;
+
+	/*
+	 * As y^PERIOD = 1/2, we can combine
+	 *    y^n = 1/2^(n/PERIOD) * y^(n%PERIOD)
+	 * With a look-up table which covers y^n (n<PERIOD)
+	 *
+	 * To achieve constant time decay_load.
+	 */
+	if (unlikely(local_n >= LOAD_AVG_PERIOD)) {
+		val >>= local_n / LOAD_AVG_PERIOD;
+		local_n %= LOAD_AVG_PERIOD;
+	}
+
+	val = mul_u64_u32_shr(val, runnable_avg_yN_inv[local_n], 32);
+	return val;
+}
+
+static u32 __accumulate_pelt_segments(u64 periods, u32 d1, u32 d3)
+{
+	u32 c1, c2, c3 = d3; /* y^0 == 1 */
+
+	/*
+	 * c1 = d1 y^p
+	 */
+	c1 = decay_load((u64)d1, periods);
+
+	/*
+	 *            p-1
+	 * c2 = 1024 \Sum y^n
+	 *            n=1
+	 *
+	 *              inf        inf
+	 *    = 1024 ( \Sum y^n - \Sum y^n - y^0 )
+	 *              n=0        n=p
+	 */
+	c2 = LOAD_AVG_MAX - decay_load(LOAD_AVG_MAX, periods) - 1024;
+
+	return c1 + c2 + c3;
+}
+
+#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
+
+/*
+ * Accumulate the three separate parts of the sum; d1 the remainder
+ * of the last (incomplete) period, d2 the span of full periods and d3
+ * the remainder of the (incomplete) current period.
+ *
+ *           d1          d2           d3
+ *           ^           ^            ^
+ *           |           |            |
+ *         |<->|<----------------->|<--->|
+ * ... |---x---|------| ... |------|-----x (now)
+ *
+ *                           p-1
+ * u' = (u + d1) y^p + 1024 \Sum y^n + d3 y^0
+ *                           n=1
+ *
+ *    = u y^p +					(Step 1)
+ *
+ *                     p-1
+ *      d1 y^p + 1024 \Sum y^n + d3 y^0		(Step 2)
+ *                     n=1
+ */
+static __always_inline u32
+accumulate_sum(u64 delta, int cpu, struct sched_avg *sa,
+	       unsigned long load, unsigned long runnable, int running)
+{
+	unsigned long scale_freq, scale_cpu;
+	u32 contrib = (u32)delta; /* p == 0 -> delta < 1024 */
+	u64 periods;
+
+	scale_freq = arch_scale_freq_capacity(cpu);
+	scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
+
+	delta += sa->period_contrib;
+	periods = delta / 1024; /* A period is 1024us (~1ms) */
+
+	/*
+	 * Step 1: decay old *_sum if we crossed period boundaries.
+	 */
+	if (periods) {
+		sa->load_sum = decay_load(sa->load_sum, periods);
+		sa->runnable_load_sum =
+			decay_load(sa->runnable_load_sum, periods);
+		sa->util_sum = decay_load((u64)(sa->util_sum), periods);
+
+		/*
+		 * Step 2
+		 */
+		delta %= 1024;
+		contrib = __accumulate_pelt_segments(periods,
+				1024 - sa->period_contrib, delta);
+	}
+	sa->period_contrib = delta;
+
+	contrib = cap_scale(contrib, scale_freq);
+	if (load)
+		sa->load_sum += load * contrib;
+	if (runnable)
+		sa->runnable_load_sum += runnable * contrib;
+	if (running)
+		sa->util_sum += contrib * scale_cpu;
+
+	return periods;
+}
+
+/*
+ * We can represent the historical contribution to runnable average as the
+ * coefficients of a geometric series.  To do this we sub-divide our runnable
+ * history into segments of approximately 1ms (1024us); label the segment that
+ * occurred N-ms ago p_N, with p_0 corresponding to the current period, e.g.
+ *
+ * [<- 1024us ->|<- 1024us ->|<- 1024us ->| ...
+ *      p0            p1           p2
+ *     (now)       (~1ms ago)  (~2ms ago)
+ *
+ * Let u_i denote the fraction of p_i that the entity was runnable.
+ *
+ * We then designate the fractions u_i as our co-efficients, yielding the
+ * following representation of historical load:
+ *   u_0 + u_1*y + u_2*y^2 + u_3*y^3 + ...
+ *
+ * We choose y based on the with of a reasonably scheduling period, fixing:
+ *   y^32 = 0.5
+ *
+ * This means that the contribution to load ~32ms ago (u_32) will be weighted
+ * approximately half as much as the contribution to load within the last ms
+ * (u_0).
+ *
+ * When a period "rolls over" and we have new u_0`, multiplying the previous
+ * sum again by y is sufficient to update:
+ *   load_avg = u_0` + y*(u_0 + u_1*y + u_2*y^2 + ... )
+ *            = u_0 + u_1*y + u_2*y^2 + ... [re-labeling u_i --> u_{i+1}]
+ */
+static __always_inline int
+___update_load_sum(u64 now, int cpu, struct sched_avg *sa,
+		  unsigned long load, unsigned long runnable, int running)
+{
+	u64 delta;
+
+	delta = now - sa->last_update_time;
+	/*
+	 * This should only happen when time goes backwards, which it
+	 * unfortunately does during sched clock init when we swap over to TSC.
+	 */
+	if ((s64)delta < 0) {
+		sa->last_update_time = now;
+		return 0;
+	}
+
+	/*
+	 * Use 1024ns as the unit of measurement since it's a reasonable
+	 * approximation of 1us and fast to compute.
+	 */
+	delta >>= 10;
+	if (!delta)
+		return 0;
+
+	sa->last_update_time += delta << 10;
+
+	/*
+	 * running is a subset of runnable (weight) so running can't be set if
+	 * runnable is clear. But there are some corner cases where the current
+	 * se has been already dequeued but cfs_rq->curr still points to it.
+	 * This means that weight will be 0 but not running for a sched_entity
+	 * but also for a cfs_rq if the latter becomes idle. As an example,
+	 * this happens during idle_balance() which calls
+	 * update_blocked_averages()
+	 */
+	if (!load)
+		runnable = running = 0;
+
+	/*
+	 * Now we know we crossed measurement unit boundaries. The *_avg
+	 * accrues by two steps:
+	 *
+	 * Step 1: accumulate *_sum since last_update_time. If we haven't
+	 * crossed period boundaries, finish.
+	 */
+	if (!accumulate_sum(delta, cpu, sa, load, runnable, running))
+		return 0;
+
+	return 1;
+}
+
+static __always_inline void
+___update_load_avg(struct sched_avg *sa, unsigned long load, unsigned long runnable)
+{
+	u32 divider = LOAD_AVG_MAX - 1024 + sa->period_contrib;
+
+	/*
+	 * Step 2: update *_avg.
+	 */
+	sa->load_avg = div_u64(load * sa->load_sum, divider);
+	sa->runnable_load_avg =	div_u64(runnable * sa->runnable_load_sum, divider);
+	sa->util_avg = sa->util_sum / divider;
+}
+
+/*
+ * sched_entity:
+ *
+ *   task:
+ *     se_runnable() == se_weight()
+ *
+ *   group: [ see update_cfs_group() ]
+ *     se_weight()   = tg->weight * grq->load_avg / tg->load_avg
+ *     se_runnable() = se_weight(se) * grq->runnable_load_avg / grq->load_avg
+ *
+ *   load_sum := runnable_sum
+ *   load_avg = se_weight(se) * runnable_avg
+ *
+ *   runnable_load_sum := runnable_sum
+ *   runnable_load_avg = se_runnable(se) * runnable_avg
+ *
+ * XXX collapse load_sum and runnable_load_sum
+ *
+ * cfq_rs:
+ *
+ *   load_sum = \Sum se_weight(se) * se->avg.load_sum
+ *   load_avg = \Sum se->avg.load_avg
+ *
+ *   runnable_load_sum = \Sum se_runnable(se) * se->avg.runnable_load_sum
+ *   runnable_load_avg = \Sum se->avg.runable_load_avg
+ */
+
+int __update_load_avg_blocked_se(u64 now, int cpu, struct sched_entity *se)
+{
+	if (entity_is_task(se))
+		se->runnable_weight = se->load.weight;
+
+	if (___update_load_sum(now, cpu, &se->avg, 0, 0, 0)) {
+		___update_load_avg(&se->avg, se_weight(se), se_runnable(se));
+		return 1;
+	}
+
+	return 0;
+}
+
+int __update_load_avg_se(u64 now, int cpu, struct cfs_rq *cfs_rq, struct sched_entity *se)
+{
+	if (entity_is_task(se))
+		se->runnable_weight = se->load.weight;
+
+	if (___update_load_sum(now, cpu, &se->avg, !!se->on_rq, !!se->on_rq,
+				cfs_rq->curr == se)) {
+
+		___update_load_avg(&se->avg, se_weight(se), se_runnable(se));
+		return 1;
+	}
+
+	return 0;
+}
+
+int __update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq)
+{
+	if (___update_load_sum(now, cpu, &cfs_rq->avg,
+				scale_load_down(cfs_rq->load.weight),
+				scale_load_down(cfs_rq->runnable_weight),
+				cfs_rq->curr != NULL)) {
+
+		___update_load_avg(&cfs_rq->avg, 1, 1);
+		return 1;
+	}
+
+	return 0;
+}
diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h
new file mode 100644
index 0000000..c312d8c
--- /dev/null
+++ b/kernel/sched/pelt.h
@@ -0,0 +1,17 @@
+#ifdef CONFIG_SMP
+
+int __update_load_avg_blocked_se(u64 now, int cpu, struct sched_entity *se);
+int __update_load_avg_se(u64 now, int cpu, struct cfs_rq *cfs_rq, struct sched_entity *se);
+int __update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq);
+
+#else
+
+static inline int
+update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
+{
+	return 0;
+}
+
+#endif
+
+
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 22909ff..783eacf 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -666,7 +666,26 @@ struct dl_rq {
 	u64			bw_ratio;
 };
 
+#ifdef CONFIG_FAIR_GROUP_SCHED
+/* An entity is a task if it doesn't "own" a runqueue */
+#define entity_is_task(se)	(!se->my_q)
+#else
+#define entity_is_task(se)	1
+#endif
+
 #ifdef CONFIG_SMP
+/*
+ * XXX we want to get rid of these helpers and use the full load resolution.
+ */
+static inline long se_weight(struct sched_entity *se)
+{
+	return scale_load_down(se->load.weight);
+}
+
+static inline long se_runnable(struct sched_entity *se)
+{
+	return scale_load_down(se->runnable_weight);
+}
 
 static inline bool sched_asym_prefer(int a, int b)
 {
-- 
2.7.4

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 2/4 v4] sched/rt: add rt_rq utilization tracking
  2018-03-16 11:25 [PATCH 0/4 v4] sched/rt: track rt rq utilization Vincent Guittot
  2018-03-16 11:25 ` [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
@ 2018-03-16 11:25 ` Vincent Guittot
  2018-04-14 10:05   ` Peter Zijlstra
  2018-03-16 11:25 ` [PATCH 3/4 v4] cpufreq/schedutil: add rt " Vincent Guittot
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 15+ messages in thread
From: Vincent Guittot @ 2018-03-16 11:25 UTC (permalink / raw)
  To: peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, dietmar.eggemann, Morten.Rasmussen, viresh.kumar,
	valentin.schneider, Vincent Guittot

schedutil governor relies on cfs_rq's util_avg to choose the OPP when cfs
tasks are running. When the CPU is overloaded by cfs and rt tasks, cfs
tasks are preempted by rt tasks and in this case util_avg reflects the
remaining capacity that is used by cfs task but not what cfs want to use.
In such case, schedutil can select a lower OPP whereas the CPU is
overloaded. In order to have a more accurate view of the utilization of
the CPU, we track the utilization that is "stolen" by RT tasks.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/fair.c  |  2 ++
 kernel/sched/pelt.c  | 23 +++++++++++++++++++++++
 kernel/sched/pelt.h  |  7 +++++++
 kernel/sched/rt.c    |  8 ++++++++
 kernel/sched/sched.h |  2 ++
 5 files changed, 42 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfd56bc..60e3c4b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7190,6 +7190,7 @@ static void update_blocked_averages(int cpu)
 		if (cfs_rq_has_blocked(cfs_rq))
 			done = false;
 	}
+	update_rt_rq_load_avg(rq_clock_task(rq), cpu, &rq->rt, 0);
 
 #ifdef CONFIG_NO_HZ_COMMON
 	rq->last_blocked_load_update_tick = jiffies;
@@ -7255,6 +7256,7 @@ static inline void update_blocked_averages(int cpu)
 	rq_lock_irqsave(rq, &rf);
 	update_rq_clock(rq);
 	update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq);
+	update_rt_rq_load_avg(rq_clock_task(rq), cpu, &rq->rt, 0);
 #ifdef CONFIG_NO_HZ_COMMON
 	rq->last_blocked_load_update_tick = jiffies;
 	if (!cfs_rq_has_blocked(cfs_rq))
diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
index d693e5e..cd51576 100644
--- a/kernel/sched/pelt.c
+++ b/kernel/sched/pelt.c
@@ -306,3 +306,26 @@ int __update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq)
 
 	return 0;
 }
+
+/*
+ * rt_rq:
+ *
+ *   util_sum = \Sum se->avg.util_sum but se->avg.util_sum is not tracked
+ *   util_sum = cpu_scale * load_sum
+ *   runnable_load_sum = load_sum
+ *
+ */
+
+int update_rt_rq_load_avg(u64 now, int cpu, struct rt_rq *rt_rq, int running)
+{
+	if (___update_load_sum(now, cpu, &rt_rq->avg,
+				running,
+				running,
+				running)) {
+
+		___update_load_avg(&rt_rq->avg, 1, 1);
+		return 1;
+	}
+
+	return 0;
+}
diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h
index c312d8c..78a2107 100644
--- a/kernel/sched/pelt.h
+++ b/kernel/sched/pelt.h
@@ -3,6 +3,7 @@
 int __update_load_avg_blocked_se(u64 now, int cpu, struct sched_entity *se);
 int __update_load_avg_se(u64 now, int cpu, struct cfs_rq *cfs_rq, struct sched_entity *se);
 int __update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq);
+int update_rt_rq_load_avg(u64 now, int cpu, struct rt_rq *rt_rq, int running);
 
 #else
 
@@ -12,6 +13,12 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
 	return 0;
 }
 
+static inline int
+update_rt_rq_load_avg(u64 now, int cpu, struct rt_rq *rt_rq, int running)
+{
+	return 0;
+}
+
 #endif
 
 
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 86b7798..c48078e 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -5,6 +5,8 @@
  */
 #include "sched.h"
 
+#include "pelt.h"
+
 int sched_rr_timeslice = RR_TIMESLICE;
 int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
 
@@ -1570,6 +1572,9 @@ pick_next_task_rt(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
 
 	rt_queue_push_tasks(rq);
 
+	update_rt_rq_load_avg(rq_clock_task(rq), cpu_of(rq), rt_rq,
+		rq->curr->sched_class == &rt_sched_class);
+
 	return p;
 }
 
@@ -1577,6 +1582,8 @@ static void put_prev_task_rt(struct rq *rq, struct task_struct *p)
 {
 	update_curr_rt(rq);
 
+	update_rt_rq_load_avg(rq_clock_task(rq), cpu_of(rq), &rq->rt, 1);
+
 	/*
 	 * The previous task needs to be made eligible for pushing
 	 * if it is still active
@@ -2306,6 +2313,7 @@ static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued)
 	struct sched_rt_entity *rt_se = &p->rt;
 
 	update_curr_rt(rq);
+	update_rt_rq_load_avg(rq_clock_task(rq), cpu_of(rq), &rq->rt, 1);
 
 	watchdog(rq, p);
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 783eacf..a8003a9 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -592,6 +592,8 @@ struct rt_rq {
 	unsigned long		rt_nr_total;
 	int			overloaded;
 	struct plist_head	pushable_tasks;
+
+	struct sched_avg avg;
 #endif /* CONFIG_SMP */
 	int			rt_queued;
 
-- 
2.7.4

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 3/4 v4] cpufreq/schedutil: add rt utilization tracking
  2018-03-16 11:25 [PATCH 0/4 v4] sched/rt: track rt rq utilization Vincent Guittot
  2018-03-16 11:25 ` [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
  2018-03-16 11:25 ` [PATCH 2/4 v4] sched/rt: add rt_rq utilization tracking Vincent Guittot
@ 2018-03-16 11:25 ` Vincent Guittot
  2018-03-16 11:25 ` [PATCH 4/4 v4] sched/nohz: monitor rt utilization Vincent Guittot
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 15+ messages in thread
From: Vincent Guittot @ 2018-03-16 11:25 UTC (permalink / raw)
  To: peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, dietmar.eggemann, Morten.Rasmussen, viresh.kumar,
	valentin.schneider, Vincent Guittot

add both cfs and rt utilization when selecting an OPP as rt can preempt and
steal cfs's running time

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/cpufreq_schedutil.c | 4 +++-
 kernel/sched/sched.h             | 7 +++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 89fe78e..7ce0643 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -56,6 +56,7 @@ struct sugov_cpu {
 	/* The fields below are only needed when sharing a policy: */
 	unsigned long		util_cfs;
 	unsigned long		util_dl;
+	unsigned long util_rt;
 	unsigned long		max;
 
 	/* The field below is for single-CPU policies only: */
@@ -178,6 +179,7 @@ static void sugov_get_util(struct sugov_cpu *sg_cpu)
 	sg_cpu->max = arch_scale_cpu_capacity(NULL, sg_cpu->cpu);
 	sg_cpu->util_cfs = cpu_util_cfs(rq);
 	sg_cpu->util_dl  = cpu_util_dl(rq);
+	sg_cpu->util_rt  = cpu_util_rt(rq);
 }
 
 static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
@@ -190,7 +192,7 @@ static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
 	} else {
 		util = sg_cpu->util_dl;
 		if (rq->cfs.h_nr_running)
-			util += sg_cpu->util_cfs;
+			util += sg_cpu->util_cfs + sg_cpu->util_rt;
 	}
 
 	/*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index a8003a9..b8784be 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2186,4 +2186,11 @@ static inline unsigned long cpu_util_cfs(struct rq *rq)
 {
 	return rq->cfs.avg.util_avg;
 }
+
+static inline unsigned long cpu_util_rt(struct rq *rq)
+{
+	return rq->rt.avg.util_avg;
+}
+
+
 #endif
-- 
2.7.4

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 4/4 v4] sched/nohz: monitor rt utilization
  2018-03-16 11:25 [PATCH 0/4 v4] sched/rt: track rt rq utilization Vincent Guittot
                   ` (2 preceding siblings ...)
  2018-03-16 11:25 ` [PATCH 3/4 v4] cpufreq/schedutil: add rt " Vincent Guittot
@ 2018-03-16 11:25 ` Vincent Guittot
  2018-04-14 10:07 ` [PATCH 0/4 v4] sched/rt: track rt rq utilization Peter Zijlstra
  2018-04-15 11:56 ` Dietmar Eggemann
  5 siblings, 0 replies; 15+ messages in thread
From: Vincent Guittot @ 2018-03-16 11:25 UTC (permalink / raw)
  To: peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, dietmar.eggemann, Morten.Rasmussen, viresh.kumar,
	valentin.schneider, Vincent Guittot

Take into account rt's utilization when deciding to stop periodic update

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/fair.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 60e3c4b..3f00e03 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7131,6 +7131,14 @@ static inline bool cfs_rq_has_blocked(struct cfs_rq *cfs_rq)
 	return false;
 }
 
+static inline bool rt_rq_has_blocked(struct rt_rq *rt_rq)
+{
+	if (rt_rq->avg.util_avg)
+		return true;
+
+	return false;
+}
+
 #ifdef CONFIG_FAIR_GROUP_SCHED
 
 static inline bool cfs_rq_is_decayed(struct cfs_rq *cfs_rq)
@@ -7191,6 +7199,9 @@ static void update_blocked_averages(int cpu)
 			done = false;
 	}
 	update_rt_rq_load_avg(rq_clock_task(rq), cpu, &rq->rt, 0);
+	/* Don't need periodic decay once load/util_avg are null */
+	if (rt_rq_has_blocked(&rq->rt))
+		done = false;
 
 #ifdef CONFIG_NO_HZ_COMMON
 	rq->last_blocked_load_update_tick = jiffies;
@@ -7259,7 +7270,7 @@ static inline void update_blocked_averages(int cpu)
 	update_rt_rq_load_avg(rq_clock_task(rq), cpu, &rq->rt, 0);
 #ifdef CONFIG_NO_HZ_COMMON
 	rq->last_blocked_load_update_tick = jiffies;
-	if (!cfs_rq_has_blocked(cfs_rq))
+	if (!cfs_rq_has_blocked(cfs_rq) && !rt_rq_has_blocked(&rq->rt))
 		rq->has_blocked_load = 0;
 #endif
 	rq_unlock_irqrestore(rq, &rf);
-- 
2.7.4

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/4 v4] sched/rt: add rt_rq utilization tracking
  2018-03-16 11:25 ` [PATCH 2/4 v4] sched/rt: add rt_rq utilization tracking Vincent Guittot
@ 2018-04-14 10:05   ` Peter Zijlstra
  2018-04-14 11:29     ` Vincent Guittot
  0 siblings, 1 reply; 15+ messages in thread
From: Peter Zijlstra @ 2018-04-14 10:05 UTC (permalink / raw)
  To: Vincent Guittot
  Cc: mingo, linux-kernel, rjw, juri.lelli, dietmar.eggemann,
	Morten.Rasmussen, viresh.kumar, valentin.schneider

On Fri, Mar 16, 2018 at 12:25:39PM +0100, Vincent Guittot wrote:
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 783eacf..a8003a9 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -592,6 +592,8 @@ struct rt_rq {
>  	unsigned long		rt_nr_total;
>  	int			overloaded;
>  	struct plist_head	pushable_tasks;
> +
> +	struct sched_avg avg;

We only want this for the root cgroup, right? So why is this per cgroup?

That is, I was expecting it to be rq::rt_avg or something.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/4 v4] sched/rt: track rt rq utilization
  2018-03-16 11:25 [PATCH 0/4 v4] sched/rt: track rt rq utilization Vincent Guittot
                   ` (3 preceding siblings ...)
  2018-03-16 11:25 ` [PATCH 4/4 v4] sched/nohz: monitor rt utilization Vincent Guittot
@ 2018-04-14 10:07 ` Peter Zijlstra
  2018-04-14 11:42   ` Vincent Guittot
  2018-04-15 11:56 ` Dietmar Eggemann
  5 siblings, 1 reply; 15+ messages in thread
From: Peter Zijlstra @ 2018-04-14 10:07 UTC (permalink / raw)
  To: Vincent Guittot
  Cc: mingo, linux-kernel, rjw, juri.lelli, dietmar.eggemann,
	Morten.Rasmussen, viresh.kumar, valentin.schneider



What I don't see in this patch-set is removal of the current rt_avg
stuff.

And I didn't look closely enough; but are the root cfs and rt pelt
windows aligned? They really should be; otherwise you can't combine them
sanely.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/4 v4] sched/rt: add rt_rq utilization tracking
  2018-04-14 10:05   ` Peter Zijlstra
@ 2018-04-14 11:29     ` Vincent Guittot
  0 siblings, 0 replies; 15+ messages in thread
From: Vincent Guittot @ 2018-04-14 11:29 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, linux-kernel, rjw, Juri Lelli, Dietmar Eggemann,
	Morten Rasmussen, viresh kumar, Valentin Schneider

On 14 April 2018 at 12:05, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, Mar 16, 2018 at 12:25:39PM +0100, Vincent Guittot wrote:
>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>> index 783eacf..a8003a9 100644
>> --- a/kernel/sched/sched.h
>> +++ b/kernel/sched/sched.h
>> @@ -592,6 +592,8 @@ struct rt_rq {
>>       unsigned long           rt_nr_total;
>>       int                     overloaded;
>>       struct plist_head       pushable_tasks;
>> +
>> +     struct sched_avg avg;
>
> We only want this for the root cgroup, right? So why is this per cgroup?

Yes it's only for root cgroup. I have put it there for consistency
with the CFS' PELT but it's only waste Bytes

>
> That is, I was expecting it to be rq::rt_avg or something.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/4 v4] sched/rt: track rt rq utilization
  2018-04-14 10:07 ` [PATCH 0/4 v4] sched/rt: track rt rq utilization Peter Zijlstra
@ 2018-04-14 11:42   ` Vincent Guittot
  0 siblings, 0 replies; 15+ messages in thread
From: Vincent Guittot @ 2018-04-14 11:42 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, linux-kernel, rjw, Juri Lelli, Dietmar Eggemann,
	Morten Rasmussen, viresh kumar, Valentin Schneider

On 14 April 2018 at 12:07, Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> What I don't see in this patch-set is removal of the current rt_avg
> stuff.

This RT load tracking doesn't replace current rt_avg because they are
not using same period and providing same function
current rt_avg uses sysctl_sched_time_avg to define the averaging
period and it's default period is 1 second. But PELT uses a fixed
period
current rt_avg is tracking irq accounting which this patch doesn't do.
This is probably doable but will need more complex changes

Replacing current rt_avg by this new RT utilization tracking would
require more complex changes so I didn't want to add them this 1st
step.


>
> And I didn't look closely enough; but are the root cfs and rt pelt
> windows aligned? They really should be; otherwise you can't combine them
> sanely.

No They are not aligned.
I agree that this could generate some variation on the sum. I'm going
to fix this point

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/4 v4] sched/rt: track rt rq utilization
  2018-03-16 11:25 [PATCH 0/4 v4] sched/rt: track rt rq utilization Vincent Guittot
                   ` (4 preceding siblings ...)
  2018-04-14 10:07 ` [PATCH 0/4 v4] sched/rt: track rt rq utilization Peter Zijlstra
@ 2018-04-15 11:56 ` Dietmar Eggemann
  2018-04-15 12:00   ` Vincent Guittot
  5 siblings, 1 reply; 15+ messages in thread
From: Dietmar Eggemann @ 2018-04-15 11:56 UTC (permalink / raw)
  To: Vincent Guittot, peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, Morten.Rasmussen, viresh.kumar, valentin.schneider

On 03/16/2018 12:25 PM, Vincent Guittot wrote:

[...]

> For a 15 seconds long test on a hikey 6220 (octo core cortex A53 platfrom),
> the cpufreq statistics outputs (stats are reset just before the test) :
> $ cat /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans
> without patchset : 1230
> with patchset : 14
> 
> If we replace the cfs thread of rt-app by a sysbench cpu test, we can see
> performance improvements:
> 
> - Without patchset :
> Test execution summary:
>      total time:                          15.0009s
>      total number of events:              4903
>      total time taken by event execution: 14.9972
>      per-request statistics:
>           min:                                  1.23ms
>           avg:                                  3.06ms
>           max:                                 13.16ms
>           approx.  95 percentile:              12.73ms
> 
> Threads fairness:
>      events (avg/stddev):           4903.0000/0.00
>      execution time (avg/stddev):   14.9972/0.00
> 
> - With patchset:
> Test execution summary:
>      total time:                          15.0014s
>      total number of events:              7694
>      total time taken by event execution: 14.9979
>      per-request statistics:
>           min:                                  1.23ms
>           avg:                                  1.95ms
>           max:                                 10.49ms
>           approx.  95 percentile:              10.39ms
> 
> Threads fairness:
>      events (avg/stddev):           7694.0000/0.00
>      execution time (avg/stddev):   14.9979/0.00
> 
> The performance improvement is 56% for this use case.

How do you get this number? Normally we use the 'total time' value.

[...]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file
  2018-03-16 11:25 ` [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
@ 2018-04-15 11:58   ` Dietmar Eggemann
  2018-04-15 12:16     ` Vincent Guittot
  2018-04-15 11:58   ` Dietmar Eggemann
  1 sibling, 1 reply; 15+ messages in thread
From: Dietmar Eggemann @ 2018-04-15 11:58 UTC (permalink / raw)
  To: Vincent Guittot, peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, Morten.Rasmussen, viresh.kumar, valentin.schneider

On 03/16/2018 12:25 PM, Vincent Guittot wrote:
> We want to track rt_rq's utilization as a part of the estimation of the
> whole rq's utilization. This is necessary because rt tasks can steal
> utilization to cfs tasks and make them lighter than they are.
> As we want to use the same load tracking mecanism for both and prevent
> useless dependency between cfs and rt code, pelt code is moved in a
> dedicated file.

This would mean that we introduce function calls into the cfs scheduler 
fast-path, something we avoided so far (e.g. the cpu and frequency 
invariance hooks). Are we OK with that?

Quentin mentioned this already during v3 review back in December.

[...]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file
  2018-03-16 11:25 ` [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
  2018-04-15 11:58   ` Dietmar Eggemann
@ 2018-04-15 11:58   ` Dietmar Eggemann
  1 sibling, 0 replies; 15+ messages in thread
From: Dietmar Eggemann @ 2018-04-15 11:58 UTC (permalink / raw)
  To: Vincent Guittot, peterz, mingo, linux-kernel, rjw
  Cc: juri.lelli, Morten.Rasmussen, viresh.kumar, valentin.schneider

On 03/16/2018 12:25 PM, Vincent Guittot wrote:

[...]

> diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h
> new file mode 100644
> index 0000000..c312d8c
> --- /dev/null
> +++ b/kernel/sched/pelt.h
> @@ -0,0 +1,17 @@
> +#ifdef CONFIG_SMP
> +
> +int __update_load_avg_blocked_se(u64 now, int cpu, struct sched_entity *se);
> +int __update_load_avg_se(u64 now, int cpu, struct cfs_rq *cfs_rq, struct sched_entity *se);
> +int __update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq);
> +
> +#else
> +
> +static inline int
> +update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
> +{
> +	return 0;
> +}
> +
> +#endif

Exporting __update_load_avg_cfs_rq() for SMP and 
update_cfs_rq_load_avg() for !SMP seems weird.

[...]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/4 v4] sched/rt: track rt rq utilization
  2018-04-15 11:56 ` Dietmar Eggemann
@ 2018-04-15 12:00   ` Vincent Guittot
  0 siblings, 0 replies; 15+ messages in thread
From: Vincent Guittot @ 2018-04-15 12:00 UTC (permalink / raw)
  To: Dietmar Eggemann
  Cc: Peter Zijlstra, Ingo Molnar, linux-kernel, rjw, Juri Lelli,
	Morten Rasmussen, viresh kumar, Valentin Schneider

Hi Dietmar,

On 15 April 2018 at 13:56, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
> On 03/16/2018 12:25 PM, Vincent Guittot wrote:
>
> [...]
>
>
>> For a 15 seconds long test on a hikey 6220 (octo core cortex A53
>> platfrom),
>> the cpufreq statistics outputs (stats are reset just before the test) :
>> $ cat /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans
>> without patchset : 1230
>> with patchset : 14
>>
>> If we replace the cfs thread of rt-app by a sysbench cpu test, we can see
>> performance improvements:
>>
>> - Without patchset :
>> Test execution summary:
>>      total time:                          15.0009s
>>      total number of events:              4903
>>      total time taken by event execution: 14.9972
>>      per-request statistics:
>>           min:                                  1.23ms
>>           avg:                                  3.06ms
>>           max:                                 13.16ms
>>           approx.  95 percentile:              12.73ms
>>
>> Threads fairness:
>>      events (avg/stddev):           4903.0000/0.00
>>      execution time (avg/stddev):   14.9972/0.00
>>
>> - With patchset:
>> Test execution summary:
>>      total time:                          15.0014s
>>      total number of events:              7694
>>      total time taken by event execution: 14.9979
>>      per-request statistics:
>>           min:                                  1.23ms
>>           avg:                                  1.95ms
>>           max:                                 10.49ms
>>           approx.  95 percentile:              10.39ms
>>
>> Threads fairness:
>>      events (avg/stddev):           7694.0000/0.00
>>      execution time (avg/stddev):   14.9979/0.00
>>
>> The performance improvement is 56% for this use case.
>
>
> How do you get this number? Normally we use the 'total time' value.

The test stop after an defined amount of time with --max-time=15 in my case

>
> [...]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file
  2018-04-15 11:58   ` Dietmar Eggemann
@ 2018-04-15 12:16     ` Vincent Guittot
  2018-04-15 13:27       ` Dietmar Eggemann
  0 siblings, 1 reply; 15+ messages in thread
From: Vincent Guittot @ 2018-04-15 12:16 UTC (permalink / raw)
  To: Dietmar Eggemann
  Cc: Peter Zijlstra, Ingo Molnar, linux-kernel, rjw, Juri Lelli,
	Morten Rasmussen, viresh kumar, Valentin Schneider

On 15 April 2018 at 13:58, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
> On 03/16/2018 12:25 PM, Vincent Guittot wrote:
>>
>> We want to track rt_rq's utilization as a part of the estimation of the
>> whole rq's utilization. This is necessary because rt tasks can steal
>> utilization to cfs tasks and make them lighter than they are.
>> As we want to use the same load tracking mecanism for both and prevent
>> useless dependency between cfs and rt code, pelt code is moved in a
>> dedicated file.
>
>
> This would mean that we introduce function calls into the cfs scheduler
> fast-path, something we avoided so far (e.g. the cpu and frequency
> invariance hooks). Are we OK with that?
>
> Quentin mentioned this already during v3 review back in December.

Yes and I hadn't seen any differences in the code size with the patch
which should have been the case if inline function where replaced by
function call


>
> [...]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file
  2018-04-15 12:16     ` Vincent Guittot
@ 2018-04-15 13:27       ` Dietmar Eggemann
  0 siblings, 0 replies; 15+ messages in thread
From: Dietmar Eggemann @ 2018-04-15 13:27 UTC (permalink / raw)
  To: Vincent Guittot
  Cc: Peter Zijlstra, Ingo Molnar, linux-kernel, rjw, Juri Lelli,
	Morten Rasmussen, viresh kumar, Valentin Schneider

On 04/15/2018 02:16 PM, Vincent Guittot wrote:
> On 15 April 2018 at 13:58, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
>> On 03/16/2018 12:25 PM, Vincent Guittot wrote:
>>>
>>> We want to track rt_rq's utilization as a part of the estimation of the
>>> whole rq's utilization. This is necessary because rt tasks can steal
>>> utilization to cfs tasks and make them lighter than they are.
>>> As we want to use the same load tracking mecanism for both and prevent
>>> useless dependency between cfs and rt code, pelt code is moved in a
>>> dedicated file.
>>
>>
>> This would mean that we introduce function calls into the cfs scheduler
>> fast-path, something we avoided so far (e.g. the cpu and frequency
>> invariance hooks). Are we OK with that?
>>
>> Quentin mentioned this already during v3 review back in December.
> 
> Yes and I hadn't seen any differences in the code size with the patch
> which should have been the case if inline function where replaced by
> function call

I see a diff (e.g. for arm64 defconfig):

6d626e0aaf91 - (HEAD -> tip/sched/core_rt_rq_util_tracking) sched/nohz: 
monitor rt utilization (2018-04-15 Vincent Guittot)
3111c6206f0c - cpufreq/schedutil: add rt utilization tracking 
(2018-04-15 Vincent Guittot)
62e103d266ed - sched/rt: add rt_rq utilization tracking (2018-04-15 
Vincent Guittot)
8f78fef6b1a2 - sched/pelt: Move pelt related code in a dedicated file 
(2018-04-15 Vincent Guittot)
31e77c93e432 - (tip/sched/core_rt_rq_util_tracking_base) sched/fair: 
Update blocked load when newly idle (2018-03-09 Vincent Guittot)

deggeman-mac:/opt/git/kernel_org:tip/sched/core_rt_rq_util_tracking$ 
size vmlinux
    text    data     bss     dec     hex filename
11286856        6154896  410296 17852048        1106690 vmlinux

versus:

31e77c93e432 - (HEAD -> tip/sched/core_rt_rq_util_tracking_base) 
sched/fair: Update blocked load when ne$
ly idle (2018-03-09 Vincent Guittot)

deggeman-mac:/opt/git/kernel_org:tip/sched/core_rt_rq_util_tracking_base$ 
size vmlinux
    text    data     bss     dec     hex filename 

11295048        6154896  410296 17860240        1108690 vmlinux

So I assume that in kernel/sched/fair.o:

U __update_load_avg_blocked_se
U __update_load_avg_cfs_rq
U __update_load_avg_se

are function calls now.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2018-04-15 13:28 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-16 11:25 [PATCH 0/4 v4] sched/rt: track rt rq utilization Vincent Guittot
2018-03-16 11:25 ` [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
2018-04-15 11:58   ` Dietmar Eggemann
2018-04-15 12:16     ` Vincent Guittot
2018-04-15 13:27       ` Dietmar Eggemann
2018-04-15 11:58   ` Dietmar Eggemann
2018-03-16 11:25 ` [PATCH 2/4 v4] sched/rt: add rt_rq utilization tracking Vincent Guittot
2018-04-14 10:05   ` Peter Zijlstra
2018-04-14 11:29     ` Vincent Guittot
2018-03-16 11:25 ` [PATCH 3/4 v4] cpufreq/schedutil: add rt " Vincent Guittot
2018-03-16 11:25 ` [PATCH 4/4 v4] sched/nohz: monitor rt utilization Vincent Guittot
2018-04-14 10:07 ` [PATCH 0/4 v4] sched/rt: track rt rq utilization Peter Zijlstra
2018-04-14 11:42   ` Vincent Guittot
2018-04-15 11:56 ` Dietmar Eggemann
2018-04-15 12:00   ` Vincent Guittot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome