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

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

On Fri, Oct 02, 2026 at 07:30:16AM -1000, Tejun Heo wrote:
> Hello, Andrea.
> 
> On Thu, Oct 01, 2026 at 09:12:16PM +0200, Andrea Righi wrote:
> > +			if ((p->scx.flags & SCX_TASK_IMMED) && !proxy_put) {
> >  				p->scx.flags |= SCX_TASK_REENQ_PREEMPTED;
> >  				scx_do_enqueue_task(rq, p, SCX_ENQ_REENQ, -1);
> 
> I wonder whether IMMED should matter for a blocked donor at all. IMMED
> should trigger a reenqueue iff the task is not being serviced by a CPU. A
> donor under proxy execution is being serviced. The CPU is working on its
> behalf and there's nothing the scheduler can do to make it go faster by
> placing it elsewhere. If so, a donor with slice left can stay on the local
> DSQ regardless of IMMED and of which put this is, and
> SCX_RQ_PROXY_PICK_PENDING isn't needed. The deferred local check would need
> the same exemption as the task stays SCX_TASK_IMMED.

I think you're right, the donor's progress depends on its mutex owner, so
re-enqueuing the donor alone can't make it run sooner. Therefore we can just
keep it local, remove SCX_RQ_PROXY_PICK_PENDING and simplify the code.

> 
> > +		/* Delegate retained donor admission to its owning BPF scheduler. */
> > +		if (p->is_blocked) {
> > +			if (WARN_ON_ONCE(!sch))
> > +				goto switch_class;
> > +			WARN_ON_ONCE(!(sch->ops.flags & SCX_OPS_ENQ_BLOCKED));
> > +			scx_do_enqueue_task(rq, p, 0, -1);
> > +			goto switch_class;
> > +		}
> 
> Can this be folded into the following block? scx_do_enqueue_task() already
> adds SCX_ENQ_BLOCKED, so a !p->is_blocked test on the ENQ_LAST condition
> would route donors to the plain enqueue.

Agreed.

Thanks!
-Andrea