Re: [PATCH 1/8] sched: Fix hrtick() vs scheduling context

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Peter,

On 9/18/2025 1:22 PM, Peter Zijlstra wrote:
> The sched_class::task_tick() method is called on the donor
> sched_class, and sched_tick() hands it rq->donor as argument, which is
> consistent.
> 
> However, while hrtick() uses the donor sched_class, it then passes
> rq->curr, which is inconsistent. Fix it.

Can we add either a:

Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")

where this starts making a difference functionally since single CPU
proxy can have rq->curr != rq->donor, or we can target the same commit
where task_tick(0 in sched_tick() was updated with:

Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts")

Other than that, this looks good to me. Feel free to include:

Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>

> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  kernel/sched/core.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -875,7 +875,7 @@ static enum hrtimer_restart hrtick(struc
>  
>  	rq_lock(rq, &rf);
>  	update_rq_clock(rq);
> -	rq->donor->sched_class->task_tick(rq, rq->curr, 1);
> +	rq->donor->sched_class->task_tick(rq, rq->donor, 1);
>  	rq_unlock(rq, &rf);
>  
>  	return HRTIMER_NORESTART;
> 
> 
> 

-- 
Thanks and Regards,
Prateek