From: Chen Yu <yu.c.chen@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
"Gautham R . Shenoy" <gautham.shenoy@amd.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
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>,
Libo Chen <libo.chen@oracle.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>,
Tim Chen <tim.c.chen@linux.intel.com>,
Aubrey Li <aubrey.li@intel.com>, Zhao Liu <zhao1.liu@intel.com>,
Chen Yu <yu.chen.surf@gmail.com>, Chen Yu <yu.c.chen@intel.com>,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH v4 26/28] sched: Do not enable cache aware scheduling for process with large RSS
Date: Sat, 9 Aug 2025 13:08:49 +0800 [thread overview]
Message-ID: <881a665a94858d4fb6f13491f4dffe58c8fc3870.1754712565.git.tim.c.chen@linux.intel.com> (raw)
In-Reply-To: <cover.1754712565.git.tim.c.chen@linux.intel.com>
It has been reported that when running memory-intensive workloads
such as stream, sched_cache may saturate the memory bandwidth on
the preferred LLC.
To prevent this from happening, evaluate the process's memory
footprint by checking the size of RSS (anonymous pages and shared
pages) and comparing it to the size of the LLC. If the former is
larger, skip cache-aware scheduling. This is because if tasks
do not actually share data, aggregating tasks with large RSS will
likely result in cache contention and performance depredation.
However, in theory, RSS is not the same as memory footprint.
This is just an estimated approach to prevent over-aggregation.
The default behavior is to strictly compare the size of RSS with
the size of the LLC. The next patch will introduce a user-provided
hint to customize this comparison.
Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
Co-developed-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-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>
---
kernel/sched/fair.c | 47 ++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4bf794f170cf..cbda7dad1305 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1205,6 +1205,34 @@ static inline int pref_llc_idx(struct task_struct *p)
return llc_idx(p->preferred_llc);
}
+static bool exceed_llc_capacity(struct mm_struct *mm, int cpu)
+{
+ struct cpu_cacheinfo *this_cpu_ci;
+ struct cacheinfo *l3_leaf;
+ 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()
+ * directly because the 'cpu' can not be
+ * offlined at the moment.
+ */
+ this_cpu_ci = get_cpu_cacheinfo(cpu);
+ if (!this_cpu_ci->info_list ||
+ this_cpu_ci->num_leaves < 3)
+ return true;
+
+ l3_leaf = this_cpu_ci->info_list + 3;
+ llc = l3_leaf->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;
@@ -1363,7 +1391,8 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
*/
if (epoch - READ_ONCE(mm->mm_sched_epoch) > sysctl_llc_old ||
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))) {
mm->mm_sched_cpu = -1;
pcpu_sched->occ = 0;
}
@@ -1448,6 +1477,14 @@ static void __no_profile task_cache_work(struct callback_head *work)
return;
}
+ /*
+ * Do not check exceed_llc_nr() because
+ * the active number of threads needs to
+ * been updated anyway.
+ */
+ if (exceed_llc_capacity(mm, curr_cpu))
+ return;
+
if (!zalloc_cpumask_var(&cpus, GFP_KERNEL))
return;
@@ -9113,8 +9150,12 @@ static __maybe_unused enum llc_mig_hint get_migrate_hint(int src_cpu, int dst_cp
if (cpu < 0)
return mig_allow;
- /* 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
+ * and large footprint.
+ */
+ if (get_nr_threads(p) <= 1 || exceed_llc_nr(mm, dst_cpu) ||
+ exceed_llc_capacity(mm, dst_cpu))
return mig_allow;
if (cpus_share_cache(dst_cpu, cpu))
--
2.25.1
next prev parent reply other threads:[~2025-08-09 5:14 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-09 4:57 [RFC PATCH v4 00/28] Cache aware load-balancing Chen Yu
2025-08-09 5:00 ` [RFC PATCH v4 01/28] sched: " Chen Yu
2025-08-12 1:30 ` kernel test robot
2025-08-12 3:26 ` Chen, Yu C
2025-08-09 5:01 ` [RFC PATCH v4 02/28] sched: Several fixes for cache aware scheduling Chen Yu
2025-08-09 5:01 ` [RFC PATCH v4 03/28] sched: Avoid task migration within its preferred LLC Chen Yu
2025-08-09 5:02 ` [RFC PATCH v4 04/28] sched: Avoid calculating the cpumask if the system is overloaded Chen Yu
2025-08-09 5:02 ` [RFC PATCH v4 05/28] sched: Add hysteresis to switch a task's preferred LLC Chen Yu
2025-09-29 13:44 ` Peter Zijlstra
2025-09-30 4:31 ` Chen, Yu C
2025-08-09 5:02 ` [RFC PATCH v4 06/28] sched: Save the per LLC utilization for better cache aware scheduling Chen Yu
2025-09-29 14:09 ` Peter Zijlstra
2025-09-30 4:34 ` Chen, Yu C
2025-08-09 5:03 ` [RFC PATCH v4 07/28] sched: Add helper function to decide whether to allow " Chen Yu
2025-10-01 13:17 ` Peter Zijlstra
2025-10-02 11:31 ` Chen, Yu C
2025-10-02 11:50 ` Peter Zijlstra
2025-10-02 12:51 ` Chen, Yu C
2025-10-02 17:46 ` Tim Chen
2025-08-09 5:03 ` [RFC PATCH v4 08/28] sched: Set up LLC indexing Chen Yu
2025-09-26 6:14 ` Adam Li
2025-09-26 13:51 ` Chen, Yu C
2025-09-29 10:43 ` Adam Li
2025-09-30 2:54 ` Chen, Yu C
2025-08-09 5:03 ` [RFC PATCH v4 09/28] sched: Introduce task preferred LLC field Chen Yu
2025-08-09 5:04 ` [RFC PATCH v4 10/28] sched: Calculate the number of tasks that have LLC preference on a runqueue Chen Yu
2025-08-09 5:04 ` [RFC PATCH v4 11/28] sched: Introduce per runqueue task LLC preference counter Chen Yu
2025-08-09 5:04 ` [RFC PATCH v4 12/28] sched: Calculate the total number of preferred LLC tasks during load balance Chen Yu
2025-08-09 5:05 ` [RFC PATCH v4 13/28] sched: Tag the sched group as llc_balance if it has tasks prefer other LLC Chen Yu
2025-08-09 5:05 ` [RFC PATCH v4 14/28] sched: Introduce update_llc_busiest() to deal with groups having preferred LLC tasks Chen Yu
2025-08-09 5:06 ` [RFC PATCH v4 15/28] sched: Introduce a new migration_type to track the preferred LLC load balance Chen Yu
2025-08-09 5:06 ` [RFC PATCH v4 16/28] sched: Consider LLC locality for active balance Chen Yu
2025-08-09 5:06 ` [RFC PATCH v4 17/28] sched: Consider LLC preference when picking tasks from busiest queue Chen Yu
2025-08-09 5:07 ` [RFC PATCH v4 18/28] sched: Do not migrate task if it is moving out of its preferred LLC Chen Yu
2025-08-09 5:07 ` [RFC PATCH v4 19/28] sched: Introduce SCHED_CACHE_LB to control cache aware load balance Chen Yu
2025-08-09 5:07 ` [RFC PATCH v4 20/28] sched: Introduce SCHED_CACHE_WAKE to control LLC aggregation on wake up Chen Yu
2025-08-09 5:07 ` [RFC PATCH v4 21/28] sched: Introduce a static key to enable cache aware only for multi LLCs Chen Yu
2025-08-09 5:07 ` [RFC PATCH v4 22/28] sched: Turn EPOCH_PERIOD and EPOCH_OLD into tunnable debugfs Chen Yu
2025-08-09 5:08 ` [RFC PATCH v4 23/28] sched: Scan a task's preferred node for preferred LLC Chen Yu
2025-08-12 1:59 ` kernel test robot
2025-08-12 3:36 ` Chen, Yu C
2025-08-09 5:08 ` [RFC PATCH v4 24/28] sched: Record average number of runninhg tasks per process Chen Yu
2025-08-09 5:08 ` [RFC PATCH v4 25/28] sched: Skip cache aware scheduling if the process has many active threads Chen Yu
2025-09-02 3:52 ` Tingyin Duan
2025-09-02 5:16 ` Tingyin Duan
2025-09-02 6:14 ` Chen, Yu C
2025-09-02 7:56 ` Duan Tingyin
2025-08-09 5:08 ` Chen Yu [this message]
2025-09-26 8:48 ` [RFC PATCH v4 26/28] sched: Do not enable cache aware scheduling for process with large RSS Adam Li
2025-09-26 14:30 ` Chen, Yu C
2025-08-09 5:09 ` [RFC PATCH v4 27/28] sched: Allow the user space to tune the scale factor for RSS comparison Chen Yu
2025-08-09 5:09 ` [RFC PATCH v4 28/28] sched: Add ftrace to track cache aware load balance and hottest CPU changes Chen Yu
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=881a665a94858d4fb6f13491f4dffe58c8fc3870.1754712565.git.tim.c.chen@linux.intel.com \
--to=yu.c.chen@intel.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=libo.chen@oracle.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@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.chen.surf@gmail.com \
--cc=zhao1.liu@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 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®