mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Cai Xinchen <caixinchen1@huawei.com>
To: <llong@redhat.com>, <tj@kernel.org>, <hannes@cmpxchg.org>,
	<mkoutny@suse.com>
Cc: <cgroups@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<lujialin4@huawei.com>, <caixinchen1@huawei.com>
Subject: [PATCH -next RFC 2/2] cpuset: Add spread_page interface to cpuset v2
Date: Tue, 30 Sep 2025 09:35:52 +0000	[thread overview]
Message-ID: <20250930093552.2842885-3-caixinchen1@huawei.com> (raw)
In-Reply-To: <20250930093552.2842885-1-caixinchen1@huawei.com>

I encountered a scenario where a machine with 1.5TB of memory,
while testing the Spark TPCDS 3TB dataset, experienced a significant
concentration of page cache usage on one of the NUMA nodes.
I discovered that the DataNode process had requested a large amount
of page cache. most of the page cache was concentrated in one NUMA node,
ultimately leading to the exhaustion of memory in that NUMA node.
At this point, all other processes in that NUMA node have to alloc
memory across NUMA nodes, or even across sockets. This eventually
caused a degradation in the end-to-end performance of the Spark test.

I do not want to restart the Spark DataNode service during business
operations. This issue can be resolved by migrating the DataNode into
a cpuset, dropping the cache, and setting cpuset.memory_spread_page to
allow it to evenly request memory. The core business threads could still
allocate local numa memory. After using cpuset.memory_spread_page, the
performance in the tpcds-99 test is improved by 2%.

The key point is that the even distribution of page cache within the
DataNode process (rather than the current NUMA distribution) does not
significantly affect end-to-end performance. However, the allocation
of core business processes, such as Executors, to the same NUMA node
does have a noticeable impact on end-to-end performance.

However, I found that cgroup v2 does not provide this interface. I
believe this interface still holds value in addressing issues caused
by uneven distribution of page cache allocation among process groups.

Thus I add cpuset.mems.spread_page to cpuset v2 interface.

Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
---
 kernel/cgroup/cpuset.c | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 3a0d443180c6..04a24642f490 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -3461,6 +3461,32 @@ void cpuset_update_task_spread_flags(struct cpuset *cs,
 		task_clear_spread_page(tsk);
 }
 
+static int cpuset_update_spread_page(struct cgroup_subsys_state *css, struct cftype *cft,
+			    u64 val)
+{
+	struct cpuset *cs = css_cs(css);
+	int retval = 0;
+
+	cpuset_full_lock();
+	if (!is_cpuset_online(cs)) {
+		retval = -ENODEV;
+		goto out_unlock;
+	}
+
+	retval = cpuset_update_flag(CS_SPREAD_PAGE, cs, val);
+
+out_unlock:
+	cpuset_full_unlock();
+	return retval;
+}
+
+static u64 cpuset_read_spread_page(struct cgroup_subsys_state *css, struct cftype *cft)
+{
+	struct cpuset *cs = css_cs(css);
+
+	return is_spread_page(cs);
+}
+
 /*
  * This is currently a minimal set for the default hierarchy. It can be
  * expanded later on by migrating more features and control files from v1.
@@ -3535,6 +3561,13 @@ static struct cftype dfl_files[] = {
 		.flags = CFTYPE_ONLY_ON_ROOT,
 	},
 
+	{
+		.name = "mems.spread_page",
+		.read_u64 = cpuset_read_spread_page,
+		.write_u64 = cpuset_update_spread_page,
+		.private = FILE_SPREAD_PAGE,
+	},
+
 	{ }	/* terminate */
 };
 
-- 
2.34.1


  parent reply	other threads:[~2025-09-30  9:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-30  9:35 [PATCH -next RFC 0/2] cpuset: Add cpuset.mems.spread_page to cgroup v2 Cai Xinchen
2025-09-30  9:35 ` [PATCH -next RFC 1/2] cpuset: Move cpuset1_update_spread_flag to cpuset Cai Xinchen
2025-09-30  9:35 ` Cai Xinchen [this message]
2025-09-30 12:05 ` [PATCH -next RFC 0/2] cpuset: Add cpuset.mems.spread_page to cgroup v2 Michal Koutný
2025-10-20  6:20   ` Cai Xinchen
2025-11-03 13:39     ` Michal Koutný
2025-11-04 12:00       ` Cai Xinchen
2025-09-30 13:57 ` Waiman Long

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=20250930093552.2842885-3-caixinchen1@huawei.com \
    --to=caixinchen1@huawei.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llong@redhat.com \
    --cc=lujialin4@huawei.com \
    --cc=mkoutny@suse.com \
    --cc=tj@kernel.org \
    /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®