[patch] sched/fair: delayed dequeued entity bias wakeup preempt short

[patch] sched/fair: delayed dequeued entity bias wakeup preempt short

[Vincent Guittot]

When checking if a shorter slice entity can preempt curr, we compare it with
the next entity to be picked but delayed dequeue entities can screw the
decision whereas they will be dequeued when picking next entity.
Dequeue them while checking for preemption as they will be dequeued anyway
when picking next entity.

Test on snapdragon rb5:
hackbench -T -p -l 16000000 -g 2 1> /dev/null &
cyclictest -t 1 -i 2777 -D 63 --policy=fair --mlock  -h 20000 -q

                     tip/sched/core  tip/sched/core    +this patch
cyclictest slice  (ms) (default)2.8             8               8
hackbench slice   (ms) (default)2.8            20              20
Total Samples          |    22559           22595           22683
Average           (us) |      157              64( 59%)        59(  8%)
Median (P50)      (us) |       57              57(  0%)        58(- 2%)
90th Percentile   (us) |       64              60(  6%)        60(  0%)
99th Percentile   (us) |     2407              67( 97%)        67(  0%)
99.9th Percentile (us) |     3400            2288( 33%)       727( 68%)
Maximum           (us) |     5037            9252(-84%)      7461( 19%)

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

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0c6b9541d864..f479666ddb9e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8987,7 +8987,7 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
 {
 	enum preempt_wakeup_action preempt_action = PREEMPT_WAKEUP_PICK;
 	struct task_struct *donor = rq->donor;
-	struct sched_entity *se = &donor->se, *pse = &p->se;
+	struct sched_entity *nse, *se = &donor->se, *pse = &p->se;
 	struct cfs_rq *cfs_rq = task_cfs_rq(donor);
 	int cse_is_idle, pse_is_idle;
 
@@ -9098,12 +9098,17 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
 	}
 
 pick:
-	/*
-	 * If @p has become the most eligible task, force preemption.
-	 */
-	if (__pick_eevdf(cfs_rq, preempt_action != PREEMPT_WAKEUP_SHORT) == pse)
+	nse = __pick_eevdf(cfs_rq, preempt_action != PREEMPT_WAKEUP_SHORT);
+	/* If @p has become the most eligible task, force preemption */
+	if (nse == pse)
 		goto preempt;
 
+	/* If the most eligible task is delayed, dequeue it and retry */
+	if (nse && nse->sched_delayed) {
+		dequeue_entities(rq, nse, DEQUEUE_SLEEP | DEQUEUE_DELAYED);
+		goto pick;
+	}
+
 	if (sched_feat(RUN_TO_PARITY))
 		update_protect_slice(cfs_rq, se);
 
-- 
2.43.0

Re: [patch] sched/fair: delayed dequeued entity bias wakeup preempt short

[Qais Yousef]

On 04/10/26 16:48, Vincent Guittot wrote:
> When checking if a shorter slice entity can preempt curr, we compare it with
> the next entity to be picked but delayed dequeue entities can screw the
> decision whereas they will be dequeued when picking next entity.
> Dequeue them while checking for preemption as they will be dequeued anyway
> when picking next entity.
> 
> Test on snapdragon rb5:
> hackbench -T -p -l 16000000 -g 2 1> /dev/null &
> cyclictest -t 1 -i 2777 -D 63 --policy=fair --mlock  -h 20000 -q
> 
>                      tip/sched/core  tip/sched/core    +this patch
> cyclictest slice  (ms) (default)2.8             8               8
> hackbench slice   (ms) (default)2.8            20              20
> Total Samples          |    22559           22595           22683
> Average           (us) |      157              64( 59%)        59(  8%)
> Median (P50)      (us) |       57              57(  0%)        58(- 2%)
> 90th Percentile   (us) |       64              60(  6%)        60(  0%)
> 99th Percentile   (us) |     2407              67( 97%)        67(  0%)
> 99.9th Percentile (us) |     3400            2288( 33%)       727( 68%)
> Maximum           (us) |     5037            9252(-84%)      7461( 19%)

Max is still high. The clear buddies patch reduces it though, I assume the
combined effect of the two deals with that?