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

[Shubhang]

Hi John,

On Wed, 21 Oct 2026, John Stultz wrote:

> 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>

Thanks for the review, agreed.
The full-nohz assumption is the important part:
sched_can_stop_tick() can legitimately stop the tick with multiple
tasks on the runqueue in the SCHED_FIFO and exactly one SCHED_RR cases.
A blocked SCHED_FIFO task can then remain rq->donor while proxy
execution runs its SCHED_NORMAL mutex owner as rq->curr.

The racy tick-stopped check can allow an extra or missed remote tick,
but is not required for the issue; the mismatch can occur while the
tick is legitimately stopped. I will clarify both points in v3 and add
your Acked-by tag.

Regards,
Shubhang Kaushik