Re: [PATCH 09/12] sched_ext: Delegate proxy donor admission to BPF schedulers

[Tejun Heo]

Hello, Andrea.

On Tue, Jul 21, 2026 at 08:31:30AM +0200, Andrea Righi wrote:
> A proxy migration preserves the donor's wake_cpu while moving its
> scheduling context to the owner's rq, so task_cpu() differs from wake_cpu
> until the donor wakes. Prevent BPF-directed migrations from pulling a
> blocked donor off this proxy rq. Otherwise each blocked re-enqueue may
> move the donor back to its callback rq only for proxy execution to move
> it to the owner again.

The description reads scattered - from here on, it's a flat list of corner
cases, one per hunk, and the design that connects them never gets stated.

> +	/* %SCX_OPS_ENQ_BLOCKED takes precedence over the fallbacks below. */
> +	enq_blocked = (sch->ops.flags & SCX_OPS_ENQ_BLOCKED) &&
> +		      p->is_blocked && !(enq_flags & SCX_ENQ_WAKEUP);
> +	if (enq_blocked)
> +		enq_flags |= SCX_ENQ_BLOCKED;
> +
>  	/* see %SCX_OPS_ENQ_EXITING */
> -	if (!(sch->ops.flags & SCX_OPS_ENQ_EXITING) &&
> +	if (!enq_blocked && !(sch->ops.flags & SCX_OPS_ENQ_EXITING) &&
>  	    unlikely(p->flags & PF_EXITING)) {
>  		__scx_add_event(sch, SCX_EV_ENQ_SKIP_EXITING, 1);
>  		goto local;
>  	}
>
>  	/* see %SCX_OPS_ENQ_MIGRATION_DISABLED */
> -	if (!(sch->ops.flags & SCX_OPS_ENQ_MIGRATION_DISABLED) &&
> +	if (!enq_blocked &&
> +	    !(sch->ops.flags & SCX_OPS_ENQ_MIGRATION_DISABLED) &&
>  	    is_migration_disabled(p)) {
>  		__scx_add_event(sch, SCX_EV_ENQ_SKIP_MIGRATION_DISABLED, 1);
>  		goto local;
>  	}

Both fallbacks repeating !enq_blocked reads awkward. How about grouping
them?

	if (enq_blocked) {
		enq_flags |= SCX_ENQ_BLOCKED;
	} else {
		/* see %SCX_OPS_ENQ_EXITING */
		if (!(sch->ops.flags & SCX_OPS_ENQ_EXITING) &&
		    unlikely(p->flags & PF_EXITING)) {
			...
		}

		/* see %SCX_OPS_ENQ_MIGRATION_DISABLED */
		if (!(sch->ops.flags & SCX_OPS_ENQ_MIGRATION_DISABLED) &&
		    is_migration_disabled(p)) {
			...
		}
	}

The "takes precedence" comment can then go away as the structure says it.

Thanks.

-- 
tejun