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

[John Stultz]

On Wed, Oct 21, 2026 at 10:15 AM Shubhang Kaushik (Ampere)
<sh@xxxxxxxxxx> 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.
> Like task_tick(), the remote tick's full-nohz interval sanity check
> currently uses rq->curr. The proxy owner in rq->curr can have a stale
> se.exec_start before the accounting path updates it.
>
> Make sched_tick_remote() use rq->donor for both the class tick and the
> full-nohz tick-interval sanity check.

Hey! Thanks for chasing this down!

Apologies, as full nohz is a bit of a blind spot for me, but it seems
the commit message gets a little lost focusing on the proxy details,
which makes it a bit harder to understand how the underlying
assumption was broken.

Maybe can I suggest reworking it to something like:
---
In sched_tick_remote(), when adding proxy-exec support, an assumption
was made, which was: we're in full dynticks mode, so there can be only
one task on the rq.  With only one task, we can assume rq->donor ==
rq->curr.  So there wasn't a need to switch rq->curr reference to
rq->donor when proxy logic was added.

However, the full nohz rules are more complex. If a SCHED_FIFO task is
running, even if there are multiple tasks on the rq,
sched_can_stop_tick() allows the tick to stop since there is no forced
preemption of SCHED_FIFO. Similarly if there is only one SCHED_RR task
the tick can be stopped even if there are other lower-sched-class
tasks on the RQ.

This means in sched_tick_remote(), there may be more tasks on the
runqueue, which means we could be proxying (if a SCHED_FIFO task is
blocked on a SCHED_NORMAL task) and and rq->donor may not equal
rq->curr.  This earlier assumption doesn't hold, and the references do
need to be switched to use rq->donor so the accounting is handled
properly, and to make it more consistent with rq->donor useage
elsewhere in the scheduler.
---

Also looking I see the comment at the top of the sched_tick_remote()
function "The [full dynticks mode] check is racy by nature" which
makes me wonder if that might also be involved here, and worth
mentioning?

The code change itself looks good to me though, so after tweaking the
commit message, feel free to add:
Acked-by: John Stultz <jstultz@xxxxxxxxxx>