From: Luo Gengkun <luogengkun2@huawei.com>
To: "Chen, Yu C" <yu.c.chen@intel.com>
Cc: <dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
<bsegall@google.com>, <mgorman@suse.de>, <vschneid@redhat.com>,
<kprateek.nayak@amd.com>, <linux-kernel@vger.kernel.org>,
<juri.lelli@redhat.com>, <vincent.guittot@linaro.org>,
<tim.c.chen@linux.intel.com>, <mingo@redhat.com>,
<peterz@infradead.org>, "chen.yu@linux.dev" <chen.yu@linux.dev>,
Jianyong Wu <jianyong.wu@outlook.com>
Subject: Re: [PATCH v9 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus
Date: Wed, 12 Aug 2026 17:03:00 +0800 [thread overview]
Message-ID: <228dff06-1cf1-413e-a1db-0aefda384479@huawei.com> (raw)
In-Reply-To: <9fae7258-5f33-4ddc-8d21-599db3c0d091@intel.com>
On 2026/8/11 15:46, Chen, Yu C wrote:
> Hi Gengkun,
> On 8/11/2026 10:27 AM, Luo Gengkun wrote:
>
> I did a further study on this and have two minor questions:
>
>>> @@ -1711,6 +1722,9 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
>>> pcpu_sched->runtime += delta_exec;
>>> rq->cpu_runtime += delta_exec;
>>> epoch = rq->cpu_epoch;
>>> + pcpu_sched->epoch_last_visit = epoch;
>>> + if (!cpumask_test_cpu(cpu_of(rq), mm->sc_stat.visited_cpus))
>>> + cpumask_set_cpu(cpu_of(rq), mm->sc_stat.visited_cpus);
>
> visited_cpus bits are only cleared inside fraction_mm_sched(), which is
> reachable in task_cache_work() - but that loop is skipped when invalid_llc_nr()
> returns true for any single-threaded process. As a result, single-threaded
> processes keep setting bits in account_mm_sched() without using them.
> Maybe a gate would be useful:
From a technical perspective, adding a gate here is unnecessary.
The overhead is virtually nonexistent, especially since it resides on a path
already burdened by heavier operations like __update_mm_sched(). If we were
to care about performance and optimization, focusing on __update_mm_sched()
would be far more meaningful than adding checks here.
What do you think?
>
> if (get_nr_threads(p) > 1 &&
> !cpumask_test_cpu(cpu_of(rq), mm->sc_stat.visited_cpus))
> cpumask_set_cpu(cpu_of(rq), mm->sc_stat.visited_cpus);
>
>
> [ ... ]
>
>>> @@ -1866,7 +1835,18 @@ static void task_cache_work(struct callback_head *work)
>>> scoped_guard (cpus_read_lock) {
>>> guard(rcu)();
>>> - get_scan_cpumasks(cpus, p);
>
> I'm thinking of if this could bring cross-node bouncing. Is it doable
> to honor the result from NUMA preference:
> get_scan_cpumasks(cpus, p);
> cpumask_and(cpus, cpus, mm->sc_stat.visited_cpus);
I looked closely at get_scan_cpumasks(). The CPU mask it returns is the
union of node(p->numa_preferred_nid), node(mm->sc_stat.cpu), and node(task_cpu(p)).
Its purpose was only to mitigate sc_stat.cpu bouncing — it did not fully
eliminate it. Relying on visited_cpus alone follows the actual footprint
of where the threads really ran, making it even less prone to bouncing.
Additionally, even if the numa node derived from visited_cpus disagrees with a
given thread's numa_preferred_nid, get_pref_llc() still prevents that
thread from being migrated to that node, so it remains safe either way.
Please let me know if I'm missing something.
thanks,
Gengkun
>
> thanks,
> Chenyu
>
next prev parent reply other threads:[~2026-08-12 9:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 2:44 [PATCH v9 0/2] Cache aware scheduling: Reduce the overhead of task_cache_work Luo Gengkun
2026-07-31 2:44 ` [PATCH v9 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus Luo Gengkun
2026-08-11 2:27 ` Luo Gengkun
2026-08-11 7:46 ` Chen, Yu C
2026-08-12 9:03 ` Luo Gengkun [this message]
2026-08-18 14:41 ` Chen, Yu C
2026-07-31 2:44 ` [PATCH v9 2/2] -- DO NOT APPLY!!! -- sched/cache/debug: Add trace event and sched feature to track scan cost Luo Gengkun
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=228dff06-1cf1-413e-a1db-0aefda384479@huawei.com \
--to=luogengkun2@huawei.com \
--cc=bsegall@google.com \
--cc=chen.yu@linux.dev \
--cc=dietmar.eggemann@arm.com \
--cc=jianyong.wu@outlook.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=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.