From: Chen Jinghuang <chenjinghuang2@huawei.com>
To: <rostedt@goodmis.org>
Cc: <bsegall@google.com>, <chenjinghuang2@huawei.com>,
<dietmar.eggemann@arm.com>, <juri.lelli@redhat.com>,
<linux-kernel@vger.kernel.org>, <mgorman@suse.de>,
<mingo@redhat.com>, <peterz@infradead.org>,
<vincent.guittot@linaro.org>, <vschneid@redhat.com>
Subject: [PATCH v2] sched/rt: Skip currently executing CPU in rto_next_cpu()
Date: Tue, 25 Nov 2025 08:36:49 +0000 [thread overview]
Message-ID: <20251125083649.1814558-1-chenjinghuang2@huawei.com> (raw)
In-Reply-To: <20251121123811.3d34b10b@gandalf.local.home>
CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound
RT task, and a CFS task stuck in kernel space. When other CPUs switch from
RT to non-RT tasks, RT load balancing (LB) is triggered; with
HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution
of rto_push_irq_work_func. During push_rt_task on CPU0,
if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED
and after the push operation completes, CPU0 calls rto_next_cpu().
Since only CPU0 is overloaded in this scenario, rto_next_cpu() should
ideally return -1 (no further IPI needed).
However, multiple CPUs invoking tell_cpu_to_push() during LB increments
rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between
rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its
search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory
&& rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to
itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and
other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,
wasting CPU cycles on unnecessary interrupt handling.
The triggering scenario is as follows:
cpu0 cpu1 cpu2
pull_rt_task
tell_cpu_to_push
<------------irq_work_queue_on
rto_push_irq_work_func
push_rt_task
resched_curr(rq) pull_rt_task
rto_next_cpu tell_cpu_to_push
<-------------------------- atomic_inc(rto_loop_next)
rd->rto_loop != next
rto_next_cpu
irq_work_queue_on
rto_push_irq_work_func
Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().
Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Chen Jinghuang <chenjinghuang2@huawei.com>
---
v1-->v2:
- Replace the original "check NEED_RESCHED on target CPU"
logic with "skip the currently executing CPU"
- This modification eliminates self-IPIS
---
---
kernel/sched/rt.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 7936d4333731..dc0d583aa59a 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2100,6 +2100,7 @@ static void push_rt_tasks(struct rq *rq)
*/
static int rto_next_cpu(struct root_domain *rd)
{
+ int this_cpu = smp_processor_id();
int next;
int cpu;
@@ -2118,14 +2119,17 @@ static int rto_next_cpu(struct root_domain *rd)
*/
for (;;) {
- /* When rto_cpu is -1 this acts like cpumask_first() */
- cpu = cpumask_next(rd->rto_cpu, rd->rto_mask);
-
- rd->rto_cpu = cpu;
+ do {
+ /* When rto_cpu is -1 this acts like cpumask_first() */
+ cpu = cpumask_next(rd->rto_cpu, rd->rto_mask);
+ rd->rto_cpu = cpu;
+ /* Do not send IPI to self */
+ } while (cpu == this_cpu);
if (cpu < nr_cpu_ids)
return cpu;
+
rd->rto_cpu = -1;
/*
--
2.34.1
next prev parent reply other threads:[~2025-11-25 8:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 1:40 [PATCH] sched/rt: rto_next_cpu: Skip CPUs with NEED_RESCHED Chen Jinghuang
2025-11-21 17:38 ` Steven Rostedt
2025-11-25 7:26 ` 回复: " chenjinghuang
2025-11-25 8:36 ` Chen Jinghuang [this message]
2025-11-25 16:26 ` [PATCH v2] sched/rt: Skip currently executing CPU in rto_next_cpu() Steven Rostedt
2025-11-26 5:54 ` [PATCH v3] " Chen Jinghuang
2025-12-04 7:35 ` [PATCH v3] sched/rt: Skip currently executing CPU in rto_next_cpu() - Request for merge Chen Jinghuang
2025-12-04 15:44 ` Steven Rostedt
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=20251125083649.1814558-1-chenjinghuang2@huawei.com \
--to=chenjinghuang2@huawei.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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®