[PATCH sched_ext/for-7.3-fixes] sched_ext: Don't report a forced-idle CPU as open for IMMED tasks

[Andrea Righi <arighi@nvidia.com>]

Core scheduling can force a CPU idle while a higher-class task is
runnable on it: under an untagged core-wide max, an incompatible pick is
replaced with idle without looking for a compatible task; rq->next_class
is then idle, so rq_is_open() reports the CPU as open and IMMED tasks
inserted into its local DSQ are parked there behind the higher-class
task, instead of going back to the BPF scheduler.

This scenario was reproduced on an SMT pair with the ext server runtime
set to 0 on both siblings: an untagged SCHED_FIFO task spinning on one
sibling forced the other idle while a tagged SCHED_FIFO task was
runnable there. An IMMED task inserted into the local DSQ of the
forced-idle sibling was never reenqueued and stayed parked for the whole
test time window. With the ext server enabled the task eventually runs,
but only once the server kicks in, so far from immediate.

Fix by reporting the CPU as busy while the donor is idle and a higher
class is runnable, except during dispatch, where the higher classes had
nothing to run. With this change the IMMED task is reenqueued right away
and the BPF scheduler runs it on another CPU.

Fixes: 98d709cba319 ("sched_ext: Implement SCX_ENQ_IMMED")
Signed-off-by: Andrea Righi <arighi@nvidia.com>
---
 kernel/sched/ext/ext.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
index 6b472506944e9..4259578186954 100644
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@ -336,6 +336,18 @@ static struct scx_dispatch_q *bypass_enq_target_dsq(struct scx_sched *sch, s32 c
 	return scx_bypass_dsq(scx_exec_sched(sch, cpu), cpu);
 }
 
+static bool higher_class_runnable(struct rq *rq)
+{
+	if (sched_stop_runnable(rq))
+		return true;
+
+	/* The ext server selects SCX tasks ahead of RT and fair tasks. */
+	if (sched_dl_runnable(rq))
+		return rb_first_cached(&rq->dl.root) != &rq->ext_server.rb_node;
+
+	return sched_rt_runnable(rq) || sched_fair_runnable(rq);
+}
+
 /**
  * rq_is_open - Is the rq available for immediate execution of an SCX task?
  * @rq: rq to test
@@ -357,6 +369,17 @@ static bool rq_is_open(struct rq *rq, u64 enq_flags)
 	if (sched_class_above(rq->next_class, &ext_sched_class))
 		return false;
 
+	/*
+	 * Core scheduling can force @rq idle while a higher-class task is
+	 * runnable on it. next_class is left at idle, or raised to ext by a
+	 * local insertion, but the blocker is picked ahead of the local DSQ
+	 * once the core cookie allows it. An in-progress dispatch means the
+	 * higher classes had nothing to run.
+	 */
+	if (rq->donor == rq->idle && !(rq->scx.flags & SCX_RQ_IN_DISPATCH) &&
+	    higher_class_runnable(rq))
+		return false;
+
 	/*
 	 * @rq is either in transition to or in idle and there is no
 	 * higher-priority class task waking up on it.
-- 
2.56.0