From: sashiko-bot@kernel.org
To: "Jianyong Wu" <wujianyong@hygon.cn>,
"Ingo Molnar" <mingo@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Juri Lelli" <juri.lelli@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Chen Yu" <yu.c.chen@intel.com>,
"Tim Chen" <tim.c.chen@linux.intel.com>
Cc: "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>,
"Shrikanth Hegde" <sshegde@linux.ibm.com>,
"Phil Auld" <pauld@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
maddy@linux.ibm.com, "Michael Ellerman" <mpe@ellerman.id.au>,
ljs@kernel.org, linux-mm@kvack.org, jianyong.wu@outlook.com,
zhongyuan@hygon.cn, huangsj@hygon.cn, wangfengyu@hygon.cn,
yingzhiwei@hygon.cn
Subject: Re: [RFC PATCH v3 16/17] sched/cache: Drop stale preferred LLC checks
Date: Fri, 30 Oct 2026 03:05:08 +0000 [thread overview]
Message-ID: <sashiko-outbox-190210@kernel.org> (raw)
In-Reply-To: <20261029025829.4005192-1-wujianyong@hygon.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] sched/fair: migrate_degrades_llc() allows unrelated tasks in migrate_llc_task
--
commit a6df5e882c3ba89fef18f6405775608279e27938
Author: Jianyong Wu <wujianyong@hygon.cn>
sched/cache: Drop stale preferred LLC checks
This commit removes the NUMA preference check in get_pref_llc() and drops
the exact preferred_llc check in migrate_degrades_llc() so that
can_migrate_llc_task() determines whether an LLC migration is allowed.
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index b93b6e6c9deae..5d11f9b7f685f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
[ ... ]
> @@ -10898,15 +10880,6 @@ static bool migrate_degrades_llc(struct task_struct *p, struct lb_env *env)
> if (env->sd->nr_balance_failed >= env->sd->cache_nice_tries + 1)
> return false;
>
> - /*
> - * We know the env->src_cpu has some tasks prefer to
> - * run on env->dst_cpu, skip the tasks do not prefer
> - * env->dst_cpu, and find the one that prefers.
> - */
> - if (env->migration_type == migrate_llc_task &&
> - READ_ONCE(p->preferred_llc) != llc_id(env->dst_cpu))
> - return true;
> -
> if (can_migrate_llc_task(env->src_cpu,
> env->dst_cpu, p) != mig_forbid)
> return false;
[Severity: Medium]
Does removing this check in migrate_degrades_llc() allow detach_tasks() to
pull unrelated tasks during a migrate_llc_task balance pass instead of the
task that actually prefers moving toward env->dst_cpu?
When a source group is classified as group_llc_balance, calculate_imbalance()
sets up a single-task migration pass:
kernel/sched/fair.c:calculate_imbalance() {
if (busiest->group_type == group_llc_balance) {
/* Move a task that prefer local LLC */
env->migration_type = migrate_llc_task;
env->imbalance = 1;
return;
}
}
And detach_tasks() stops as soon as a single task passes can_migrate_task():
kernel/sched/fair.c:detach_tasks() {
case migrate_llc_task:
env->imbalance--;
break;
}
Without a check restricting migrate_llc_task to tasks that gain LLC affinity
by moving to env->dst_cpu, migrate_degrades_llc() relies solely on
can_migrate_llc_task(env->src_cpu, env->dst_cpu, p) != mig_forbid.
However, can_migrate_llc_task() returns mig_unrestricted for kernel threads
(!p->mm), tasks with mm->sc_stat.cpu < 0, single-threaded tasks matching
invalid_llc_nr(), and tasks matching exceed_llc_capacity():
kernel/sched/fair.c:can_migrate_llc_task() {
mm = p->mm;
if (!mm)
return mig_unrestricted;
cpu = READ_ONCE(mm->sc_stat.cpu);
if (cpu < 0 || cpus_share_cache(src_cpu, dst_cpu))
return mig_unrestricted;
/* skip cache aware load balance for too many threads */
if (invalid_llc_nr(mm, p, dst_cpu) ||
exceed_llc_capacity(mm, dst_cpu)) {
if (READ_ONCE(mm->sc_stat.cpu) != -1)
WRITE_ONCE(mm->sc_stat.cpu, -1);
return mig_unrestricted;
}
to_pref = if_to_prefer(src_cpu, dst_cpu, llc_id(cpu));
return can_migrate_llcs(src_cpu, dst_cpu,
p, to_pref);
}
In addition, when to_pref is false, can_migrate_llcs() can still return
mig_unrestricted or mig_llc. And when env->tol <= 1, update_sg_lb_stats()
and sched_balance_find_src_rq() only count affinity_score for tasks with
p->preferred_llc == llc_id(env->dst_cpu), whereas can_migrate_llc_task()
calls if_to_prefer() unconditionally.
If any such unrelated task precedes the target task on env->src_rq->cfs_tasks
(or if the target task is currently running on env->src_rq), won't
detach_tasks() detach the wrong task, decrement env->imbalance to 0, exit the
loop early, and also prevent need_active_balance() from migrating the running
LLC-preferring task?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261029022036.4002331-1-wujianyong@hygon.cn?part=16
next prev parent reply other threads:[~2026-10-30 3:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 2:20 [RFC PATCH v3 00/17] sched: Scale cache-aware aggregation at LLC granularity Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 01/17] sched/topology: Add llc_to_node() to translate LLC ID to NUMA node Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 02/17] sched/topology: Build NUMA node affinity sequences Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 03/17] sched/topology: Add an iterator for cached NUMA node affinity rows Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 04/17] sched/topology: Build triangular affinity orders for LLCs in a node Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 05/17] sched/topology: Walk LLCs in NUMA node Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 06/17] sched/cache: Prioritize cache-preferred node selection over LLC selection Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 07/17] sched/topology: Add per-sd scratch for cache-aware load balancing Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 08/17] sched/cache: Introduce helpers for task migration decisions Jianyong Wu
2026-10-30 3:04 ` sashiko-bot
2026-10-29 2:20 ` [RFC PATCH v3 09/17] sched/cache: Introduce rq affinity gain calculation Jianyong Wu
2026-10-30 3:05 ` sashiko-bot
2026-10-29 2:20 ` [RFC PATCH v3 10/17] sched/cache: Pick the source rq/group with the highest affinity gain Jianyong Wu
2026-10-30 3:05 ` sashiko-bot
2026-10-29 2:20 ` [RFC PATCH v3 11/17] sched/cache: Drop prefer_sibling restriction for llc_balance Jianyong Wu
2026-10-29 2:20 ` [RFC PATCH v3 12/17] sched/cache: Apply multi-LLC aggregation policy to task migration Jianyong Wu
2026-10-30 3:05 ` sashiko-bot
2026-10-29 2:45 ` [RFC PATCH v3 13/17] sched/cache: Allow active balance to spread load from a full LLC Jianyong Wu
2026-10-30 3:05 ` sashiko-bot
2026-10-29 2:50 ` [RFC PATCH v3 14/17] sched/cache: Consider LLC load when selecting a single-task source rq Jianyong Wu
2026-10-29 2:56 ` [RFC PATCH v3 15/17] sched/cache: Include recently used preferred nodes in LLC scans Jianyong Wu
2026-10-30 3:05 ` sashiko-bot
2026-10-29 2:58 ` [RFC PATCH v3 16/17] sched/cache: Drop stale preferred LLC checks Jianyong Wu
2026-10-30 3:05 ` sashiko-bot [this message]
2026-10-29 2:59 ` [RFC PATCH v3 17/17] sched/debug: Show cache placement and preferred LLC in /proc/<pid>/sched Jianyong Wu
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=sashiko-outbox-190210@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bsegall@google.com \
--cc=david@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=huangsj@hygon.cn \
--cc=jianyong.wu@outlook.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sshegde@linux.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=wangfengyu@hygon.cn \
--cc=wujianyong@hygon.cn \
--cc=yingzhiwei@hygon.cn \
--cc=yu.c.chen@intel.com \
--cc=zhongyuan@hygon.cn \
/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