[PATCH 0/2] for sched-devel.git

[PATCH 0/2] for sched-devel.git

[Peter Zijlstra]

Hi Ingo,

Would you stick these into sched-devel.

The first patch should address the latency isolation issue. While the second
rectifies a massive brainfart :-)

[PATCH 1/2] sched: fair: virtual deadline scheduling

[Peter Zijlstra]

[-- Attachment #1: sched-fair-deadline.patch --]
[-- Type: text/plain, Size: 2177 bytes --]

Change CFS into a virtual deadline scheduler.

By flattening the grouping hierarchy into a single level we now end up with
tasks that have varying latency requirements. Tasks from group A might have a
larger latency period than those from group B as the period depends on the
number of runnable tasks within a group.

The current scheduling criteria does not take that into account - it assumes a
single latency period. In order to accommodate these varying latencies in the
scheduling decision, move to EDF [*] scheduling. We treat the tasks need + its
latency period as the deadline it has to meet. This includes the latency into
the scheduling decision.

[*] - EDF is correct up until load 1, after that it is not a closed system so
improvement is possible here. It is usable because the system strives to
generate the load 1 situation.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 include/linux/sched.h |    1 +
 kernel/sched_fair.c   |    6 +++++-
 2 files changed, 6 insertions(+), 1 deletion(-)

Index: linux-2.6/include/linux/sched.h
===================================================================
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -925,6 +925,7 @@ struct sched_entity {
 	u64			exec_start;
 	u64			sum_exec_runtime;
 	u64			vruntime;
+	u64			vperiod;
 	u64			prev_sum_exec_runtime;
 
 #ifdef CONFIG_SCHEDSTATS
Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -220,9 +220,11 @@ static inline u64 min_vruntime(u64 min_v
 
 static inline s64 entity_key(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
-	return se->vruntime - cfs_rq->min_vruntime;
+	return se->vruntime + se->vperiod - cfs_rq->min_vruntime;
 }
 
+static u64 sched_vslice_add(struct cfs_rq *cfs_rq, struct sched_entity *se);
+
 /*
  * Enqueue an entity into the rb-tree:
  */
@@ -240,6 +242,8 @@ static void __enqueue_entity(struct cfs_
 	if (se == cfs_rq->curr)
 		return;
 
+	se->vperiod = sched_vslice_add(cfs_rq, se);
+
 	cfs_rq = &rq_of(cfs_rq)->cfs;
 
 	link = &cfs_rq->tasks_timeline.rb_node;

--

[PATCH 2/2] sched: fair: fix calc_delta_asym

[Peter Zijlstra]

[-- Attachment #1: sched-fair-asym.patch --]
[-- Type: text/plain, Size: 1132 bytes --]

The goal of calc_delta_asym() is to be asymetrically around NICE_0_LOAD, in
that it favours >=0 over <0. The current implementation does not achieve that.

 -20         |
             |
   0 --------+-------
           .'
  19     .'

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 kernel/sched_fair.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -417,12 +417,17 @@ calc_delta_fair(unsigned long delta, str
 static inline unsigned long
 calc_delta_asym(unsigned long delta, struct sched_entity *se)
 {
-	unsigned long fair = calc_delta_fair(delta, se);
+	if (se->load.weight < NICE_0_LOAD) {
+		struct load_weight lw = {
+			.weight = NICE_0_LOAD,
+			.inv_weight = 1UL << (WMULT_SHIFT-NICE_0_SHIFT)
+		};
 
-	if (fair > delta)
-		fair = delta;
+		delta = calc_delta_mine(delta, cfs_rq_of(se)->load.weight, &lw);
+		se = parent_entity(se);
+	}
 
-	return fair;
+	return calc_delta_fair(delta, se);
 }
 
 /*

--

Re: [PATCH 0/2] for sched-devel.git

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> Hi Ingo,
> 
> Would you stick these into sched-devel.
> 
> The first patch should address the latency isolation issue. While the 
> second rectifies a massive brainfart :-)

hehe :-) applied.

	Ingo