From: Huang Shijie <shijie@os.amperecomputing.com>
To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, vschneid@redhat.com
Cc: patches@amperecomputing.com, cl@linux.com,
Shubhang@os.amperecomputing.com, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
linux-kernel@vger.kernel.org,
Huang Shijie <shijie@os.amperecomputing.com>
Subject: [PATCH v4] sched/fair: do not scan twice in detach_tasks()
Date: Mon, 21 Jul 2025 10:39:39 +0800 [thread overview]
Message-ID: <20250721023939.19703-1-shijie@os.amperecomputing.com> (raw)
detach_tasks() uses struct lb_env.loop_max as an env.src_rq->cfs_tasks
iteration count limit. It is however set without the source RQ lock held,
and besides detach_tasks() can be re-invoked after releasing and
re-acquiring the RQ lock per LBF_NEED_BREAK.
This means that env.loop_max and the actual length of env.src_rq->cfs_tasks
as observed within detach_tasks() can differ. This can cause some tasks to
be unnecessarily iterated over more than once, for instance:
env.loop_max := 4
detach_tasks()
// Here env.src->cfs_tasks only contains two tasks which can't be
// migrated anywhere, so they're put back in the list each time.
env.src->cfs_tasks := [p1, p0]
// The iteration goes:
p0; cfs_tasks := [p0, p1]
p1; cfs_tasks := [p1, p0]
p0; cfs_tasks := [p0, p1]
p1; cfs_tasks := [p1, p0]
// IOW we iterate over each task twice
In the Specjbb test, the similar issues can be caught many times.
(Over 330,000 times in a 30-minites Specjbb test)
The patch introduces "first_back" to record the first task which
is put back to the task list. If we get a task which is equal to
first_back, we break the loop, and avoid to scan twice for it.
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
---
v3 --> v4:
Changed the commit message suggested by Valentin Schneider.
v3: https://lore.kernel.org/all/20250718063523.9232-1-shijie@os.amperecomputing.com/
v2 --> v3:
Fix a typo in the commit message.
v2: https://lore.kernel.org/all/20250718054709.8781-1-shijie@os.amperecomputing.com/
v1 --> v2:
Add more comment from Valentin Schneider
v1: https://lore.kernel.org/all/20250707083636.38380-1-shijie@os.amperecomputing.com/
---
kernel/sched/fair.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e2963efe800..7cc9d50e3e11 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9443,6 +9443,7 @@ static int detach_tasks(struct lb_env *env)
{
struct list_head *tasks = &env->src_rq->cfs_tasks;
unsigned long util, load;
+ struct task_struct *first_back = NULL;
struct task_struct *p;
int detached = 0;
@@ -9481,6 +9482,12 @@ static int detach_tasks(struct lb_env *env)
}
p = list_last_entry(tasks, struct task_struct, se.group_node);
+ /*
+ * We're back to an already visited task that couldn't be
+ * detached, we've seen all there is to see.
+ */
+ if (p == first_back)
+ break;
if (!can_migrate_task(p, env))
goto next;
@@ -9562,6 +9569,8 @@ static int detach_tasks(struct lb_env *env)
schedstat_inc(p->stats.nr_failed_migrations_hot);
list_move(&p->se.group_node, tasks);
+ if (!first_back)
+ first_back = p;
}
/*
--
2.40.1
next reply other threads:[~2025-07-21 2:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 2:39 Huang Shijie [this message]
2025-07-21 9:40 ` Vincent Guittot
2025-07-21 11:25 ` Valentin Schneider
2025-07-22 3:26 ` Shijie Huang
2025-07-22 7:49 ` Vincent Guittot
2025-07-22 7:53 ` Vincent Guittot
2025-07-22 9:01 ` Valentin Schneider
2025-07-22 9:40 ` Shijie Huang
2025-07-22 3:16 ` Shijie Huang
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=20250721023939.19703-1-shijie@os.amperecomputing.com \
--to=shijie@os.amperecomputing.com \
--cc=Shubhang@os.amperecomputing.com \
--cc=bsegall@google.com \
--cc=cl@linux.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=patches@amperecomputing.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®