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

[Shubhang Kaushik (Ampere)]

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>
---
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,
-- 
Shubhang Kaushik (Ampere) <sh@xxxxxxxxxx>