From: "Shubhang Kaushik (Ampere)" <sh@gentwo.org>
To: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Connor O'Brien <connoro@google.com>,
John Stultz <jstultz@google.com>,
Shubhang Kaushik <shubhang@os.amperecomputing.com>,
"Christoph Lameter (Ampere)" <cl@gentwo.org>
Cc: linux-kernel@vger.kernel.org,
"Shubhang Kaushik (Ampere)" <sh@gentwo.org>
Subject: [PATCH v2] sched/core: Use the scheduling context for remote ticks
Date: Wed, 21 Oct 2026 10:15:29 -0700 [thread overview]
Message-ID: <20261021-remote-tick-proxy-v2-1-07890601a71e@gentwo.org> (raw)
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.
Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
Signed-off-by: Shubhang Kaushik (Ampere) <sh@gentwo.org>
---
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 v2 patched kernel completed the same 10 minute workload
without scheduler warnings or locktorture failures.
Changes in v2:
- Use rq->donor for the full-nohz tick-interval sanity check.
- Drop the redundant proxy-execution code comment.
Link to v1: https://lore.kernel.org/r/20261016-remote-tick-proxy-v1-1-272757a50a07@gentwo.org
---
kernel/sched/core.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0ab15f03cb947eb958ff9f97d890716346377889..729ebaca35e1a9a12cda59e96c650ee6b1576951 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5934,26 +5934,20 @@ 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)) {
+ if (!is_idle_task(donor)) {
/*
* Make sure the next tick runs within a
* reasonable amount of time.
*/
- u64 delta = rq_clock_task(rq) - curr->se.exec_start;
+ u64 delta = rq_clock_task(rq) - donor->se.exec_start;
WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 30);
}
- curr->sched_class->task_tick(rq, curr, 0);
+ donor->sched_class->task_tick(rq, donor, 0);
calc_load_nohz_remote(rq);
}
---
base-commit: a804c5742bff224d4cb4d25dd383554d598be32b
change-id: 20261016-remote-tick-proxy-237fc1da63c8
Best regards,
--
Shubhang Kaushik (Ampere) <sh@gentwo.org>
next reply other threads:[~2026-10-21 17:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 17:15 Shubhang Kaushik (Ampere) [this message]
2026-10-21 20:09 ` John Stultz
2026-10-21 23:12 ` Shubhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261021-remote-tick-proxy-v2-1-07890601a71e@gentwo.org \
--to=sh@gentwo.org \
--cc=bsegall@google.com \
--cc=cl@gentwo.org \
--cc=connoro@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shubhang@os.amperecomputing.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®