Re: [PATCH] sched/core: Use the scheduling context for remote ticks

[Christian Loehle]

On 10/16/26 22:13, Shubhang Kaushik (Ampere) wrote:
> sched_tick_remote() invokes task_tick() for rq->curr. With proxy
> execution, rq->curr is the mutex-owner execution context while
> rq->donor is the blocked task that supplies the scheduling context.
> 
> A mutex-blocked task remains queued for proxy execution. If that task
> is SCHED_FIFO, or the only SCHED_RR task, sched_can_stop_tick() permits
> the full-nohz tick to stop. find_proxy_task() can then select its mutex
> owner as rq->curr while retaining the blocked task as rq->donor.
> 
> sched_tick() and hrtick() already invoke task_tick() for rq->donor.
> Make sched_tick_remote() do the same. Keep rq->curr for the execution
> time sanity check.
> 
> Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
> 
> Signed-off-by: Shubhang Kaushik (Ampere) <sh@xxxxxxxxxx>


NIT: no empty newline between the above two

> ---
> Testing was performed on an Ampere Altra system with
> CONFIG_SCHED_PROXY_EXEC=y and CONFIG_NO_HZ_FULL=y, booted with:
> 
>   sched_proxy_exec=1 nohz_full=78
> 
> On the unpatched baseline: 70dd4ee72eb2 (7.3.0-rc7), mutex locktorture
> with four writers pinned to CPU 78 and RT boosting triggered:
> 
>   WARNING: kernel/sched/core.c:5895 at sched_tick_remote...
>   Workqueue: events_unbound sched_tick_remote
> 
> This warning is WARN_ON_ONCE(rq->curr != rq->donor), demonstrating that
> a full-nohz remote tick can run while the executing task and scheduling
> context differ.
> 
> The patched kernel completed the same 10-minute workload without
> scheduler warnings or locktorture failures.
> ---
>  kernel/sched/core.c | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1fe40de6ebe3cb9a8cfa2e6104a2a4cd4515f739..14aab4cde12b4dc9cccf45087ca956ecec2aa379 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5885,14 +5885,9 @@ static void sched_tick_remote(struct work_struct *work)
>  	if (tick_nohz_tick_stopped_cpu(cpu)) {
>  		guard(rq_lock_irq)(rq);
>  		struct task_struct *curr = rq->curr;
> +		struct task_struct *donor = rq->donor;
>  
>  		if (cpu_online(cpu)) {
> -			/*
> -			 * Since this is a remote tick for full dynticks mode,
> -			 * we are always sure that there is no proxy (only a
> -			 * single task is running).
> -			 */
> -			WARN_ON_ONCE(rq->curr != rq->donor);
>  			update_rq_clock(rq);
>  
>  			if (!is_idle_task(curr)) {
> @@ -5903,7 +5898,11 @@ static void sched_tick_remote(struct work_struct *work)
>  				u64 delta = rq_clock_task(rq) - curr->se.exec_start;
>  				WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 30);
>  			}
> -			curr->sched_class->task_tick(rq, curr, 0);
> +			/*
> +			 * Proxy execution runs the mutex owner in @curr on behalf of the
> +			 * blocked task in @donor. The scheduler tick applies to @donor.
> +			 */
> +			donor->sched_class->task_tick(rq, donor, 0);
>  
>  			calc_load_nohz_remote(rq);
>  		}
> 
> ---
> base-commit: 70dd4ee72eb2d5793c62e71c14e3aba78e5a4e56
> change-id: 20261016-remote-tick-proxy-237fc1da63c8
> 
> Best regards,

The sashiko review looks legitimate, mind picking that up, too?
https://sashiko.dev/#/patchset/20261016-remote-tick-proxy-v1-1-272757a50a07%40gentwo.org