Re: [PATCH v4 sched_ext/for-7.4] sched_ext: Keep proxy donors with slice left on the local DSQ

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

thanks for taking a look at this! I investigated both cases with a reproducer in
virtme-ng. Your second finding is reproducible, the first remains a plausible
path, but I haven't reproduced it yet.

On Wed, Oct 14, 2026 at 12:10:44PM -1000, Tejun Heo wrote:
> Hello, Andrea.
> 
> The following is a Claude-generated review.
> 
> Two issues found while going through the patch. Both are from reading
> the code and neither has been reproduced.
> 
> SCX_RQ_PROXY_PENDING can stay set into a core-sched forced idle:
> 
> 1. A blocked donor is picked and set_next_task_scx() sets the flag.
> 
> 2. find_proxy_task() returns NULL without putting the donor because
>    blocked_on changed or the owner moved, and __schedule() goes to
>    pick_again.
> 
> 3. On the core-sched path, a fair or RT task wins pick_task() on this
>    rq, so pick_task_scx() does not run and the flag is not cleared.
> 
> 4. The cookie does not match and the CPU is forced idle.
>    put_prev_set_next_task(rq, donor, idle) sees the flag and
>    put_prev_task_scx() takes it as a bookkeeping put.

I was able to force the abandoned-pick path, but I haven't observed it continue
into the false bookkeeping put. Looking at the code it seems legit and the flag
can be stale on that path.

I think we can safeguard put_prev_task_scx() by treating the put as a proxy put
only if the donor's cookie also matches the CPU and a cookie mismatch takes the
ordinary forced-idle path.

> 
> An IMMED donor then stays on the local DSQ through the forced idle, and
> a donor without slice goes to ops.enqueue() without SCX_ENQ_LAST. Maybe
> clear the flag when find_proxy_task() abandons the pick?
> 
> On an IMMED bookkeeping put, the local DSQ insert always queues a reenq
> scan from dsq_inc_nr(). rq->next_class is still ext there, as
> proxy_resched_idle() lowers it to idle only after the put, so
> rq_is_open() is false. The scan is a no-op once the CPU is in idle.
> 
> However, if an SCX task wakes up on the CPU before the scan runs, the
> wakeup raises rq->next_class back to ext and task_woken_scx() runs the
> pending scan, which sees the rq closed and sends the donor back to BPF.
> That is the ops.enqueue() round trip the patch is meant to remove. Can
> you take a look?

I was able to reproduce this one. In a baseline run, I counted 174 across 2000
measured mutex trials.

I have a local prototype that sets a flag (SCX_TASK_DSQ_PROXY_IDLE) in
p->scx.dsq_flags for the donor, when a proxy put parks it on the local DSQ and
clears the flag when the task leaves the DSQ. When the rq donor is idle,
rq_is_open() checks for that flag on the task at the DSQ head and also checks
its core-scheduling cookie. This prevents the pending scan from sending that
donor back to BPF. It's yet another flag, I know..., but in this way everything
is self contained in ext.c.

The prototype passed the reproducer in virtme-ng with zero blocked IMMED
reenqueues across the 2000 measured trials in all configurations: same-CPU and
cross-CPU owners, with/without SCX_OPS_ENQ_BLOCKED.

I'll do more testing and send a follow-up fix.

Thanks,
-Andrea