From: Waiman Long <longman@redhat.com>
To: "Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Hocko" <mhocko@kernel.org>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Muchun Song" <muchun.song@linux.dev>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Tejun Heo" <tj@kernel.org>, "Michal Koutný" <mkoutny@suse.com>,
"Shuah Khan" <shuah@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
Sean Christopherson <seanjc@google.com>,
James Houghton <jthoughton@google.com>,
Sebastian Chlad <sebastianchlad@gmail.com>,
Guopeng Zhang <zhangguopeng@kylinos.cn>,
Li Wang <liwan@redhat.com>, Waiman Long <longman@redhat.com>
Subject: [PATCH v2 5/7] selftests: memcg: Reduce the expected swap.peak with larger page size
Date: Fri, 20 Mar 2026 16:42:39 -0400 [thread overview]
Message-ID: <20260320204241.1613861-6-longman@redhat.com> (raw)
In-Reply-To: <20260320204241.1613861-1-longman@redhat.com>
When running the test_memcg_swap_max_peak test which sets swap.max
to 30M on an arm64 system with 64k page size, the test failed as the
swap.peak could only reach up only to 27,328,512 bytes (about 25.45
MB which is lower than the expected 29M) before the allocating task
got oom-killed.
It is likely due to the fact that it takes longer to write out a larger
page to swap and hence a lower swap.peak is being reached. Setting
memory.high to 29M to throttle memory allocation when nearing memory.max
helps, but it still could only reach up to 29,032,448 bytes (about
27.04M). As a result, we have to reduce the expected swap.peak with
larger page size. Now swap.peak is expected to reach only 27M with 64k
page, 29M with 4k page and 28M with 16k page.
Signed-off-by: Waiman Long <longman@redhat.com>
---
.../selftests/cgroup/test_memcontrol.c | 26 ++++++++++++++++---
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testing/selftests/cgroup/test_memcontrol.c
index c078fc458def..3832ded1e47b 100644
--- a/tools/testing/selftests/cgroup/test_memcontrol.c
+++ b/tools/testing/selftests/cgroup/test_memcontrol.c
@@ -1032,6 +1032,7 @@ static int test_memcg_swap_max_peak(const char *root)
char *memcg;
long max, peak;
struct stat ss;
+ long swap_peak;
int swap_peak_fd = -1, mem_peak_fd = -1;
/* any non-empty string resets */
@@ -1119,6 +1120,23 @@ static int test_memcg_swap_max_peak(const char *root)
if (cg_write(memcg, "memory.max", "30M"))
goto cleanup;
+ /*
+ * The swap.peak that can be reached will depend on the system page
+ * size. With larger page size (e.g. 64k), it takes more time to write
+ * the anonymous memory page to swap and so the peak reached will be
+ * lower before the memory allocation process get oom-killed. One way
+ * to allow the swap.peak to go higher is to throttle memory allocation
+ * by setting memory.high to, say, 29M to give more time to swap out the
+ * memory before oom-kill. This is still not enough for it to reach
+ * 29M reachable with 4k page. So we still need to reduce the expected
+ * swap.peak accordingly.
+ */
+ swap_peak = (page_size == KB(4)) ? MB(29) :
+ ((page_size <= KB(16)) ? MB(28) : MB(27));
+
+ if (cg_write(memcg, "memory.high", "29M"))
+ goto cleanup;
+
/* Should be killed by OOM killer */
if (!cg_run(memcg, alloc_anon, (void *)MB(100)))
goto cleanup;
@@ -1134,7 +1152,7 @@ static int test_memcg_swap_max_peak(const char *root)
goto cleanup;
peak = cg_read_long(memcg, "memory.swap.peak");
- if (peak < MB(29))
+ if (peak < swap_peak)
goto cleanup;
peak = cg_read_long_fd(mem_peak_fd);
@@ -1142,7 +1160,7 @@ static int test_memcg_swap_max_peak(const char *root)
goto cleanup;
peak = cg_read_long_fd(swap_peak_fd);
- if (peak < MB(29))
+ if (peak < swap_peak)
goto cleanup;
/*
@@ -1181,7 +1199,7 @@ static int test_memcg_swap_max_peak(const char *root)
if (cg_read_long(memcg, "memory.peak") < MB(29))
goto cleanup;
- if (cg_read_long(memcg, "memory.swap.peak") < MB(29))
+ if (cg_read_long(memcg, "memory.swap.peak") < swap_peak)
goto cleanup;
if (cg_run(memcg, alloc_anon_50M_check_swap, (void *)MB(30)))
@@ -1196,7 +1214,7 @@ static int test_memcg_swap_max_peak(const char *root)
goto cleanup;
peak = cg_read_long(memcg, "memory.swap.peak");
- if (peak < MB(29))
+ if (peak < swap_peak)
goto cleanup;
peak = cg_read_long_fd(mem_peak_fd);
--
2.53.0
next prev parent reply other threads:[~2026-03-20 20:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 20:42 [PATCH v2 0/7] selftests: memcg: Fix test_memcontrol test failures with large page sizes Waiman Long
2026-03-20 20:42 ` [PATCH v2 1/7] memcg: Scale up vmstats flush threshold with int_sqrt(nr_cpus+2) Waiman Long
2026-03-23 12:46 ` Li Wang
2026-03-24 0:15 ` Yosry Ahmed
2026-03-25 16:47 ` Waiman Long
2026-03-25 17:23 ` Yosry Ahmed
2026-03-20 20:42 ` [PATCH v2 2/7] memcg: Scale down MEMCG_CHARGE_BATCH with increase in PAGE_SIZE Waiman Long
2026-03-23 12:47 ` Li Wang
2026-03-24 0:17 ` Yosry Ahmed
2026-03-20 20:42 ` [PATCH v2 3/7] selftests: memcg: Iterate pages based on the actual page size Waiman Long
2026-03-23 2:53 ` Li Wang
2026-03-23 2:56 ` Li Wang
2026-03-25 3:33 ` Waiman Long
2026-03-20 20:42 ` [PATCH v2 4/7] selftests: memcg: Increase error tolerance in accordance with " Waiman Long
2026-03-23 8:01 ` Li Wang
2026-03-25 16:42 ` Waiman Long
2026-03-20 20:42 ` Waiman Long [this message]
2026-03-23 8:24 ` [PATCH v2 5/7] selftests: memcg: Reduce the expected swap.peak with larger " Li Wang
2026-03-25 3:47 ` Waiman Long
2026-03-20 20:42 ` [PATCH v2 6/7] selftests: memcg: Don't call reclaim_until() if already in target Waiman Long
2026-03-23 8:53 ` Li Wang
2026-03-20 20:42 ` [PATCH v2 7/7] selftests: memcg: Treat failure for zeroing sock in test_memcg_sock as XFAIL Waiman Long
2026-03-23 9:44 ` Li Wang
2026-03-21 1:16 ` [PATCH v2 0/7] selftests: memcg: Fix test_memcontrol test failures with large page sizes Andrew Morton
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=20260320204241.1613861-6-longman@redhat.com \
--to=longman@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jthoughton@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liwan@redhat.com \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=sebastianchlad@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=tj@kernel.org \
--cc=zhangguopeng@kylinos.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