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

[Tejun Heo <tj@kernel.org>]

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.

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?

Thanks.

-- 
tejun