Re: [PATCH sched_ext/for-7.4-fixes] sched_ext: Avoid unnecessary IMMED reenqueues on idle CPUs

[Tejun Heo]

Hello, Andrea.

On Wed, Oct 28, 2026 at 05:52:58PM +0100, Andrea Righi wrote:
> +	/*
> +	 * A local insertion can raise next_class to ext while the donor is
> +	 * still idle, including after proxy_resched_idle(). The local DSQ head
> +	 * is next to run if its cookie matches, so keep it through IMMED reenq.
> +	 */
> +	if (rq->donor == rq->idle) {
> +		struct task_struct *first = first_local_task(rq);
> +
> +		if (first && sched_cpu_cookie_match(rq, first))
> +			return true;
> +	}

Can you leave the core-sched cookie check out of this patch? IMMED
doesn't handle core scheduling correctly in other places either, e.g.
when core scheduling forces a CPU idle, nothing reenqueues the IMMED
tasks left on its local DSQ. Core sched should be addressed in its own
patch.

Also, the check as written doesn't work on an idle core.
sched_cpu_cookie_match() compares the task's cookie against
rq->core->core_cookie, which the core-wide pick sets from the
max-priority pick, so it's 0 when the whole core is idle. A task with a
cookie that wakes on an idle core fails the check and still gets
reenqueued even though the next core-wide pick would run it.

> -		if (p->migration_pending)
> +		if (p->migration_pending) {
> +			reenq_flags |= SCX_REENQ_TSR_NOT_FIRST;
>  			continue;
> +		}
>
> -		if (!scx_is_descendant(task_sch, sch))
> +		if (!scx_is_descendant(task_sch, sch)) {
> +			reenq_flags |= SCX_REENQ_TSR_NOT_FIRST;
>  			continue;
> +		}

Can you split this out into a separate patch? Skipped tasks not taking
the first position is a gap that has existed since the IMMED
implementation and is independent of the rq_is_open() change.

Thanks.

--
tejun