Skip to content

Commit 17e3e88

Browse files
vingu-linaroPeter Zijlstra
authored andcommitted
sched/fair: Fix pelt lost idle time detection
The check for some lost idle pelt time should be always done when pick_next_task_fair() fails to pick a task and not only when we call it from the fair fast-path. The case happens when the last running task on rq is a RT or DL task. When the latter goes to sleep and the /Sum of util_sum of the rq is at the max value, we don't account the lost of idle time whereas we should. Fixes: 6769243 ("sched: Rework pick_next_task() slow-path") Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
1 parent ee6e44d commit 17e3e88

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

kernel/sched/fair.c

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -8920,21 +8920,21 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf
89208920
return p;
89218921

89228922
idle:
8923-
if (!rf)
8924-
return NULL;
8925-
8926-
new_tasks = sched_balance_newidle(rq, rf);
8923+
if (rf) {
8924+
new_tasks = sched_balance_newidle(rq, rf);
89278925

8928-
/*
8929-
* Because sched_balance_newidle() releases (and re-acquires) rq->lock, it is
8930-
* possible for any higher priority task to appear. In that case we
8931-
* must re-start the pick_next_entity() loop.
8932-
*/
8933-
if (new_tasks < 0)
8934-
return RETRY_TASK;
8926+
/*
8927+
* Because sched_balance_newidle() releases (and re-acquires)
8928+
* rq->lock, it is possible for any higher priority task to
8929+
* appear. In that case we must re-start the pick_next_entity()
8930+
* loop.
8931+
*/
8932+
if (new_tasks < 0)
8933+
return RETRY_TASK;
89358934

8936-
if (new_tasks > 0)
8937-
goto again;
8935+
if (new_tasks > 0)
8936+
goto again;
8937+
}
89388938

89398939
/*
89408940
* rq is about to be idle, check if we need to update the

0 commit comments

Comments
 (0)