Re: [PATCH RFC v3] sched/proxy: Defer donor commit until after proxy resolution

[K Prateek Nayak]

Hello Xukai,

On 10/10/2026 6:27 PM, Xukai Wang wrote:
> So the measurable effect is at the donor commit point itself: deferring
> the commit reduced the number of put_prev_task()/set_next_task() callback
> invocations by 81.7%, with the measured callback time at that point
> dropping from about 11.29 ms to 2.52 ms per workload run.
> 
> Separately from the measured cost, this also places the scheduling-class
> state commit after the donor has survived proxy resolution, rather than
> committing state for a candidate that may subsequently be abandoned.
> 
> I'd appreciate your thoughts on whether these measurements address the
> concern from v2, and whether there are any changes you'd like to see for
> v4.

I don't have any real concern except you'll have to rebase it on latest
tip and handle the scx changes. Also in your v3 ...

On 8/27/2026 2:48 PM, Xukai Wang wrote:
> @@ -7143,45 +7159,49 @@ static void __sched notrace __schedule(int sched_mode)
>  
>  pick_again:
>  	assert_balance_callbacks_empty(rq);
> -	next = pick_next_task(rq, &rf);
> -	rq->next_class = next->sched_class;
> +	donor = pick_next_task(rq, &rf);
> +	rq->next_class = donor->sched_class;
> +	next = donor;
>  	if (sched_proxy_exec()) {
> -		struct task_struct *prev_donor = rq->donor;
> -
> -		rq_set_donor(rq, next);
> -		next->blocked_donor = NULL;
> -		if (unlikely(next->is_blocked)) {
> -			next = find_proxy_task(rq, next, &rf);
> -			if (!next) {
> -				zap_balance_callbacks(rq);
> +		donor->blocked_donor = NULL;
> +		if (unlikely(donor->is_blocked)) {
> +			struct sched_dl_entity *donor_dl_server = rq->dl_server;
> +
> +			rq->dl_server = NULL;

I'm not able to understand this special dl_server handling.

In case of "pick_again", pick_next_task() will clear the rq->dl_server
before the pick and for "keep_resched" with idle task, I don't think the
dl_server from pick makes any difference since we'll come back into
schedule right after the switch.

For rest of find_proxy_task() we don't really care about dl_server afaict
unless I'm missing something. did you trip something that required this
change?

> +
> +			next = find_proxy_task(rq, donor, &rf);
> +			if (!next)
>  				goto pick_again;
> -			}
> -			if (next == rq->idle) {
> -				zap_balance_callbacks(rq);
> +			if (next == rq->idle)
>  				goto keep_resched;
> -			}
> -		}
> -		if (rq->donor == prev_donor && prev != next) {
> -			struct task_struct *donor = rq->donor;
> -			/*
> -			 * When transitioning like:
> -			 *
> -			 *         prev         next
> -			 * donor:    B            B
> -			 * curr:     A          B or C
> -			 *
> -			 * then put_prev_set_next_task() will not have done
> -			 * anything, since B == B. However, A might have
> -			 * missed a RT/DL balance opportunity due to being
> -			 * on_cpu.
> -			 */
> -			donor->sched_class->put_prev_task(rq, donor, donor);
> -			donor->sched_class->set_next_task(rq, donor, true);
> +
> +			rq->dl_server = donor_dl_server;
>  		}
> -	} else {
> -		rq_set_donor(rq, next);
> +
>  	}
>  
> +	put_prev_set_next_task(rq, rq->donor, donor);
> +
> +	if (sched_proxy_exec() &&
> +	    donor == rq->donor && prev != next) {

nit. That condition is too short to need splitting into two.

> +		/*
> +		 * When transitioning like:
> +		 *
> +		 *         prev         next
> +		 * donor:    B            B
> +		 * curr:     A          B or C
> +		 *
> +		 * then put_prev_set_next_task() will not have called
> +		 * the class->put_prev_task()/set_next_task() callbacks,
> +		 * since B == B. However, A might have missed a RT/DL
> +		 * balance opportunity due to being on_cpu.
> +		 */
> +		donor->sched_class->put_prev_task(rq, donor, donor);
> +		donor->sched_class->set_next_task(rq, donor, true);
> +	}
> +
> +	rq_set_donor(rq, donor);


(+ Andrea for sched-ext)

On current tip + sched-ext changes lined for v7.4 from
https://lore.kernel.org/lkml/20260922165445.943315-9-arighi@xxxxxxxxxx/
some sched-ext bits will need rq->donor to already reflect the next
selection before they are called and three "if (sched_proxy_exec() ...)"
splits in schedule() looks all over the place.

I'm not sure if 8ms overhead is that visible in a real world workload
especially where SCHED_PROXY_EXEC brings much more benefit to balance
that overhead.

I'll let John, Peter, and Andrea comment further - last I remember,
Peter preferred keeping all the sched_proxy_exec() related bits in a
single place in __schedule().

> +
>  picked:
>  	clear_tsk_need_resched(prev);
>  	clear_preempt_need_resched();
> 

-- 
Thanks and Regards,
Prateek