sched: fully ignore RT tasks for CFS load-balancing
RFC PATCH 1/1 sched: fully ignore RT tasks for CFS load-balancing
Since -rt runs IRQs and SoftIRQs as RT tasks and load-balancing is done from softirq context, there is always at least one RT task (and very likely multiple) running when we balance.
The current (and totally broken) interaction between RT tasks and CFS load-balancing makes it so that we'll try to evacuate a significant amount of tasks due to RT tasks being runnable.
Solve this in another broken way by not accounting RT tasks at all.
This will likely break another class of cases, but until we can properly fix this, we might as well do this.
--- kernel/sched_rt.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-)
kernel/sched_rt.c +0 -0
@@ -926,8 +926,6 @@ static void enqueue_task_rt(struct rq *rq, struct
task_struct *p, int wakeup)
if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1)
enqueue_pushable_task(rq, p);
-
- inc_cpu_load(rq, p->se.load.weight);
}
static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int
sleep)
@@ -942,8 +940,6 @@ static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int sleep)
dequeue_rt_entity(rt_se);
dequeue_pushable_task(rq, p);
-
- dec_cpu_load(rq, p->se.load.weight);
}
/*
Quoted 4 lines · Peter Zijlstra
Since -rt runs IRQs and SoftIRQs as RT tasks and load-balancing is done from softirq context, there is always at least one RT task (and very likely multiple) running when we balance.
Quoted 8 lines
The current (and totally broken) interaction between RT tasks and CFS load-balancing makes it so that we'll try to evacuate a significant amount of tasks due to RT tasks being runnable.
Solve this in another broken way by not accounting RT tasks at all.
This will likely break another class of cases, but until we can properly fix this, we might as well do this.
Peter,
Do we know why this became a problem lately? I don't recall seeing load balancing issues like this way back around 2.6.21 or 22 when CFS was released. Is the cpu_load stuff fairly recent?
--
Darren
Quoted 38 lines
Chucked-on-by Peter Zijlstra <[email protected]>--- kernel/sched_rt.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-)kernel/sched_rt.c +0
-2@@ -926,8 +926,6 @@ static void enqueue_task_rt(struct rq *rq, struct task_struct *p, int wakeup)if (!task_current (rq, p) && p->rt.nr_cpus_allowed >1 )enqueue_pushable_task (rq, p); - -inc_cpu_load (rq, p->se.load.weight); }static void dequeue_task_rt(struct rq *rq, struct
task_struct*p, int
sleep)kernel/sched_rt.c +0
-2@@ -942,8 +940,6 @@ static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int sleep)dequeue_rt_entity (rt_se );dequeue_pushable_task (rq, p); - -dec_cpu_load (rq, p->se.load.weight); }/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 3 lines
Darren Hart IBM Linux Technology Center Real-Time Linux Team
Quoted 11 lines · Darren Hart
Quoted 10 lines · Peter Zijlstra
Since -rt runs IRQs and SoftIRQs as RT tasks and load-balancing is done from softirq context, there is always at least one RT task (and very likely multiple) running when we balance.
The current (and totally broken) interaction between RT tasks and CFS load-balancing makes it so that we'll try to evacuate a significant amount of tasks due to RT tasks being runnable.
Solve this in another broken way by not accounting RT tasks at all.
Quoted 8 lines
Quoted 2 lines
This will likely break another class of cases, but until we can properly fix this, we might as well do this.
Peter,
Do we know why this became a problem lately? I don't recall seeing load balancing issues like this way back around 2.6.21 or 22 when CFS was released. Is the
cpu_loadstuff fairly recent?
The earlier problem solved by the previous patch was caused by tglx tinkering with the cpu_load computation.
This particular problem I'm not sure about, afaict it should have been present a long long time.