From: Vern Hao <haoxing990@gmail.com>
To: Tim Chen <tim.c.chen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
Vincent Guittot <vincent.guittot@linaro.org>
Cc: Chen Yu <yu.c.chen@intel.com>, Juri Lelli <juri.lelli@redhat.com>,
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>,
Madadi Vineeth Reddy <vineethr@linux.ibm.com>,
Hillf Danton <hdanton@sina.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Jianyong Wu <jianyong.wu@outlook.com>,
Yangyu Chen <cyy@cyyself.name>,
Tingyin Duan <tingyin.duan@gmail.com>,
Vern Hao <vernhao@tencent.com>, Len Brown <len.brown@intel.com>,
Aubrey Li <aubrey.li@intel.com>, Zhao Liu <zhao1.liu@intel.com>,
Chen Yu <yu.chen.surf@gmail.com>,
Adam Li <adamli@os.amperecomputing.com>,
Aaron Lu <ziqianlu@bytedance.com>,
Tim Chen <tim.c.chen@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 19/23] sched/cache: Avoid cache-aware scheduling for memory-heavy processes
Date: Thu, 18 Dec 2025 11:59:57 +0800 [thread overview]
Message-ID: <91a7c325-5093-4417-aa98-34df694b0c39@gmail.com> (raw)
In-Reply-To: <f1acf9ae29b7f69f3c74492b77d780a242343dfe.1764801860.git.tim.c.chen@linux.intel.com>
On 2025/12/4 07:07, Tim Chen wrote:
> From: Chen Yu <yu.c.chen@intel.com>
>
> Prateek and Tingyin reported that memory-intensive workloads (such as
> stream) can saturate memory bandwidth and caches on the preferred LLC
> when sched_cache aggregates too many threads.
>
> To mitigate this, estimate a process's memory footprint by comparing
> its RSS (anonymous and shared pages) to the size of the LLC. If RSS
> exceeds the LLC size, skip cache-aware scheduling.
Restricting RSS prevents many applications from benefiting from this
optimization. I believe this restriction should be lifted. For
memory-intensive workloads, the optimization may simply yield no gains,
but it certainly shouldn't make performance worse. We need to further
refine this logic.
> Note that RSS is only an approximation of the memory footprint.
> By default, the comparison is strict, but a later patch will allow
> users to provide a hint to adjust this threshold.
>
> According to the test from Adam, some systems do not have shared L3
> but with shared L2 as clusters. In this case, the L2 becomes the LLC[1].
>
> Link[1]: https://lore.kernel.org/all/3cb6ebc7-a2fd-42b3-8739-b00e28a09cb6@os.amperecomputing.com/
>
> Co-developed-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
> ---
>
> Notes:
> v1->v2: Assigned curr_cpu in task_cache_work() before checking
> exceed_llc_capacity(mm, curr_cpu) to avoid out-of-bound
> access.(lkp/0day)
>
> include/linux/cacheinfo.h | 21 ++++++++++-------
> kernel/sched/fair.c | 49 +++++++++++++++++++++++++++++++++++----
> 2 files changed, 57 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index c8f4f0a0b874..82d0d59ca0e1 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -113,18 +113,11 @@ int acpi_get_cache_info(unsigned int cpu,
>
> const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
>
> -/*
> - * Get the cacheinfo structure for the cache associated with @cpu at
> - * level @level.
> - * cpuhp lock must be held.
> - */
> -static inline struct cacheinfo *get_cpu_cacheinfo_level(int cpu, int level)
> +static inline struct cacheinfo *_get_cpu_cacheinfo_level(int cpu, int level)
> {
> struct cpu_cacheinfo *ci = get_cpu_cacheinfo(cpu);
> int i;
>
> - lockdep_assert_cpus_held();
> -
> for (i = 0; i < ci->num_leaves; i++) {
> if (ci->info_list[i].level == level) {
> if (ci->info_list[i].attributes & CACHE_ID)
> @@ -136,6 +129,18 @@ static inline struct cacheinfo *get_cpu_cacheinfo_level(int cpu, int level)
> return NULL;
> }
>
> +/*
> + * Get the cacheinfo structure for the cache associated with @cpu at
> + * level @level.
> + * cpuhp lock must be held.
> + */
> +static inline struct cacheinfo *get_cpu_cacheinfo_level(int cpu, int level)
> +{
> + lockdep_assert_cpus_held();
> +
> + return _get_cpu_cacheinfo_level(cpu, level);
> +}
> +
> /*
> * Get the id of the cache associated with @cpu at level @level.
> * cpuhp lock must be held.
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 6afa3f9a4e9b..424ec601cfdf 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1223,6 +1223,38 @@ static int llc_id(int cpu)
> return llc;
> }
>
> +static bool exceed_llc_capacity(struct mm_struct *mm, int cpu)
> +{
> + struct cacheinfo *ci;
> + unsigned long rss;
> + unsigned int llc;
> +
> + /*
> + * get_cpu_cacheinfo_level() can not be used
> + * because it requires the cpu_hotplug_lock
> + * to be held. Use _get_cpu_cacheinfo_level()
> + * directly because the 'cpu' can not be
> + * offlined at the moment.
> + */
> + ci = _get_cpu_cacheinfo_level(cpu, 3);
> + if (!ci) {
> + /*
> + * On system without L3 but with shared L2,
> + * L2 becomes the LLC.
> + */
> + ci = _get_cpu_cacheinfo_level(cpu, 2);
> + if (!ci)
> + return true;
> + }
Is there must call it one by one for get llc size? a static variable
instead in building sched domain?
> +
> + llc = ci->size;
> +
> + rss = get_mm_counter(mm, MM_ANONPAGES) +
> + get_mm_counter(mm, MM_SHMEMPAGES);
> +
> + return (llc <= (rss * PAGE_SIZE));
> +}
> +
> static bool exceed_llc_nr(struct mm_struct *mm, int cpu)
> {
> int smt_nr = 1;
> @@ -1382,7 +1414,8 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
> */
> if (epoch - READ_ONCE(mm->mm_sched_epoch) > EPOCH_LLC_AFFINITY_TIMEOUT ||
> get_nr_threads(p) <= 1 ||
> - exceed_llc_nr(mm, cpu_of(rq))) {
> + exceed_llc_nr(mm, cpu_of(rq)) ||
> + exceed_llc_capacity(mm, cpu_of(rq))) {
> if (mm->mm_sched_cpu != -1)
> mm->mm_sched_cpu = -1;
> }
> @@ -1439,7 +1472,7 @@ static void __no_profile task_cache_work(struct callback_head *work)
> struct mm_struct *mm = p->mm;
> unsigned long m_a_occ = 0;
> unsigned long curr_m_a_occ = 0;
> - int cpu, m_a_cpu = -1, nr_running = 0;
> + int cpu, m_a_cpu = -1, nr_running = 0, curr_cpu;
> cpumask_var_t cpus;
>
> WARN_ON_ONCE(work != &p->cache_work);
> @@ -1449,7 +1482,9 @@ static void __no_profile task_cache_work(struct callback_head *work)
> if (p->flags & PF_EXITING)
> return;
>
> - if (get_nr_threads(p) <= 1) {
> + curr_cpu = task_cpu(p);
> + if (get_nr_threads(p) <= 1 ||
> + exceed_llc_capacity(mm, curr_cpu)) {
> if (mm->mm_sched_cpu != -1)
> mm->mm_sched_cpu = -1;
>
> @@ -9895,8 +9930,12 @@ static enum llc_mig can_migrate_llc_task(int src_cpu, int dst_cpu,
> if (cpu < 0 || cpus_share_cache(src_cpu, dst_cpu))
> return mig_unrestricted;
>
> - /* skip cache aware load balance for single/too many threads */
> - if (get_nr_threads(p) <= 1 || exceed_llc_nr(mm, dst_cpu))
> + /*
> + * Skip cache aware load balance for single/too many threads
> + * or large footprint.
> + */
> + if (get_nr_threads(p) <= 1 || exceed_llc_nr(mm, dst_cpu) ||
> + exceed_llc_capacity(mm, dst_cpu))
> return mig_unrestricted;
>
> if (cpus_share_cache(dst_cpu, cpu))
next prev parent reply other threads:[~2025-12-18 5:55 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-03 23:07 [PATCH v2 00/23] Cache aware scheduling Tim Chen
2025-12-03 23:07 ` [PATCH v2 01/23] sched/cache: Introduce infrastructure for cache-aware load balancing Tim Chen
2025-12-09 11:12 ` Peter Zijlstra
2025-12-09 21:39 ` Tim Chen
2025-12-10 9:37 ` Peter Zijlstra
2025-12-10 13:57 ` Chen, Yu C
2025-12-10 15:11 ` Peter Zijlstra
2025-12-11 9:03 ` Vern Hao
2025-12-16 6:12 ` Chen, Yu C
2025-12-17 1:17 ` Vern Hao
2026-01-15 21:47 ` Tim Chen
[not found] ` <fbf52d91-0605-4608-b9cc-e8cc56115fd5@gmail.com>
2025-12-16 22:30 ` Tim Chen
2025-12-03 23:07 ` [PATCH v2 02/23] sched/cache: Record per-LLC utilization to guide cache-aware scheduling decisions Tim Chen
2025-12-09 11:21 ` Peter Zijlstra
2025-12-10 14:02 ` Chen, Yu C
2025-12-10 15:13 ` Peter Zijlstra
2025-12-10 23:58 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 03/23] sched/cache: Introduce helper functions to enforce LLC migration policy Tim Chen
2026-01-22 18:13 ` Yangyu Chen
2026-01-22 20:43 ` Tim Chen
2025-12-03 23:07 ` [PATCH v2 04/23] sched/cache: Make LLC id continuous Tim Chen
2025-12-09 11:58 ` Peter Zijlstra
2025-12-15 20:49 ` Tim Chen
2025-12-16 5:31 ` Chen, Yu C
2025-12-16 19:53 ` Tim Chen
2025-12-17 5:25 ` Chen, Yu C
2025-12-23 5:31 ` K Prateek Nayak
2025-12-24 7:08 ` Chen, Yu C
2025-12-24 8:19 ` K Prateek Nayak
2025-12-24 9:46 ` Chen, Yu C
2025-12-26 3:17 ` K Prateek Nayak
2025-12-03 23:07 ` [PATCH v2 05/23] sched/cache: Assign preferred LLC ID to processes Tim Chen
2025-12-09 12:11 ` Peter Zijlstra
2025-12-09 22:34 ` Tim Chen
2025-12-12 3:34 ` Vern Hao
2025-12-15 19:32 ` Tim Chen
2025-12-19 4:01 ` Vern Hao
2025-12-24 10:20 ` Chen, Yu C
2026-01-07 4:49 ` Jianyong Wu
2026-01-07 8:38 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 06/23] sched/cache: Track LLC-preferred tasks per runqueue Tim Chen
2025-12-09 12:16 ` Peter Zijlstra
2025-12-09 22:55 ` Tim Chen
2025-12-10 9:42 ` Peter Zijlstra
2025-12-16 0:20 ` Chen, Yu C
2025-12-17 10:04 ` Vern Hao
2025-12-17 12:37 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 07/23] sched/cache: Introduce per runqueue task LLC preference counter Tim Chen
2025-12-09 13:06 ` Peter Zijlstra
2025-12-09 23:17 ` Tim Chen
2025-12-10 12:43 ` Peter Zijlstra
2025-12-10 18:36 ` Tim Chen
2025-12-10 12:51 ` Peter Zijlstra
2025-12-10 18:49 ` Tim Chen
2025-12-11 10:31 ` Peter Zijlstra
2025-12-15 19:21 ` Tim Chen
2025-12-16 22:45 ` Tim Chen
2025-12-03 23:07 ` [PATCH v2 08/23] sched/cache: Calculate the per runqueue task LLC preference Tim Chen
2025-12-03 23:07 ` [PATCH v2 09/23] sched/cache: Count tasks prefering destination LLC in a sched group Tim Chen
2025-12-10 12:52 ` Peter Zijlstra
2025-12-10 14:05 ` Chen, Yu C
2025-12-10 15:16 ` Peter Zijlstra
2025-12-10 19:00 ` Tim Chen
2025-12-10 23:50 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 10/23] sched/cache: Check local_group only once in update_sg_lb_stats() Tim Chen
2025-12-03 23:07 ` [PATCH v2 11/23] sched/cache: Prioritize tasks preferring destination LLC during balancing Tim Chen
2025-12-03 23:07 ` [PATCH v2 12/23] sched/cache: Add migrate_llc_task migration type for cache-aware balancing Tim Chen
2025-12-10 13:32 ` Peter Zijlstra
2025-12-16 0:52 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 13/23] sched/cache: Handle moving single tasks to/from their preferred LLC Tim Chen
2025-12-03 23:07 ` [PATCH v2 14/23] sched/cache: Consider LLC preference when selecting tasks for load balancing Tim Chen
2025-12-10 15:58 ` Peter Zijlstra
2025-12-03 23:07 ` [PATCH v2 15/23] sched/cache: Respect LLC preference in task migration and detach Tim Chen
2025-12-10 16:30 ` Peter Zijlstra
2025-12-16 7:30 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 16/23] sched/cache: Introduce sched_cache_present to enable cache aware scheduling for multi LLCs NUMA node Tim Chen
2025-12-10 16:32 ` Peter Zijlstra
2025-12-10 16:52 ` Peter Zijlstra
2025-12-16 7:36 ` Chen, Yu C
2025-12-16 7:31 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 17/23] sched/cache: Record the number of active threads per process for cache-aware scheduling Tim Chen
2025-12-10 16:51 ` Peter Zijlstra
2025-12-16 7:40 ` Chen, Yu C
2025-12-17 9:40 ` Aaron Lu
2025-12-17 12:51 ` Chen, Yu C
2025-12-19 3:32 ` Aaron Lu
2025-12-03 23:07 ` [PATCH v2 18/23] sched/cache: Disable cache aware scheduling for processes with high thread counts Tim Chen
2025-12-03 23:07 ` [PATCH v2 19/23] sched/cache: Avoid cache-aware scheduling for memory-heavy processes Tim Chen
2025-12-18 3:59 ` Vern Hao [this message]
2025-12-18 8:32 ` Chen, Yu C
2025-12-18 9:42 ` Vern Hao
2025-12-19 3:14 ` K Prateek Nayak
2025-12-19 12:55 ` Chen, Yu C
2025-12-22 2:49 ` Vern Hao
2025-12-22 2:19 ` Vern Hao
2025-12-03 23:07 ` [PATCH v2 20/23] sched/cache: Add user control to adjust the parameters of cache-aware scheduling Tim Chen
2025-12-10 17:02 ` Peter Zijlstra
2025-12-16 7:42 ` Chen, Yu C
2025-12-19 4:14 ` Vern Hao
2025-12-19 13:21 ` Chen, Yu C
2025-12-19 13:39 ` Chen, Yu C
2025-12-23 12:12 ` Yangyu Chen
2025-12-23 16:44 ` Yangyu Chen
2025-12-24 3:28 ` Yangyu Chen
2025-12-24 7:51 ` Chen, Yu C
2025-12-24 12:15 ` Yangyu Chen
2026-01-15 10:03 ` Jianyong Wu
2026-01-15 12:13 ` Chen, Yu C
2026-01-21 15:21 ` Yangyu Chen
2026-01-21 15:38 ` Chen, Yu C
2025-12-03 23:07 ` [PATCH v2 21/23] -- DO NOT APPLY!!! -- sched/cache/stats: Add schedstat for cache aware load balancing Tim Chen
2025-12-19 5:03 ` Yangyu Chen
2025-12-19 14:41 ` Chen, Yu C
2025-12-19 14:48 ` Yangyu Chen
2025-12-03 23:07 ` [PATCH v2 22/23] -- DO NOT APPLY!!! -- sched/cache/debug: Add ftrace to track the load balance statistics Tim Chen
2025-12-03 23:07 ` [PATCH v2 23/23] -- DO NOT APPLY!!! -- sched/cache/debug: Display the per LLC occupancy for each process via proc fs Tim Chen
2025-12-17 9:59 ` Aaron Lu
2025-12-17 13:01 ` Chen, Yu C
2025-12-19 3:19 ` [PATCH v2 00/23] Cache aware scheduling Aaron Lu
2025-12-19 13:04 ` Chen, Yu C
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=91a7c325-5093-4417-aa98-34df694b0c39@gmail.com \
--to=haoxing990@gmail.com \
--cc=adamli@os.amperecomputing.com \
--cc=aubrey.li@intel.com \
--cc=bsegall@google.com \
--cc=cyy@cyyself.name \
--cc=dietmar.eggemann@arm.com \
--cc=gautham.shenoy@amd.com \
--cc=hdanton@sina.com \
--cc=jianyong.wu@outlook.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sshegde@linux.ibm.com \
--cc=tim.c.chen@intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=tingyin.duan@gmail.com \
--cc=vernhao@tencent.com \
--cc=vincent.guittot@linaro.org \
--cc=vineethr@linux.ibm.com \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@gmail.com \
--cc=zhao1.liu@intel.com \
--cc=ziqianlu@bytedance.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®