Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  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