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: 67692435c411 ("sched: Rework pick_next_task() slow-path")
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bc0b7ce8a65d6bbe616953f530f7a02bb619537c..cee1793e8277a2f9f9e3536172769ee554b1bf6c 100644 (file)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8920,21 +8920,21 @@ simple:
        return p;
 
 idle:
-       if (!rf)
-               return NULL;
-
-       new_tasks = sched_balance_newidle(rq, rf);
+       if (rf) {
+               new_tasks = sched_balance_newidle(rq, rf);
 
-       /*
-        * Because sched_balance_newidle() releases (and re-acquires) rq->lock, it is
-        * possible for any higher priority task to appear. In that case we
-        * must re-start the pick_next_entity() loop.
-        */
-       if (new_tasks < 0)
-               return RETRY_TASK;
+               /*
+                * Because sched_balance_newidle() releases (and re-acquires)
+                * rq->lock, it is possible for any higher priority task to
+                * appear. In that case we must re-start the pick_next_entity()
+                * loop.
+                */
+               if (new_tasks < 0)
+                       return RETRY_TASK;
 
-       if (new_tasks > 0)
-               goto again;
+               if (new_tasks > 0)
+                       goto again;
+       }
 
        /*
         * rq is about to be idle, check if we need to update the