[LTP] [PATCH v1] memcontrol03: Bind to single CPU on systems with 64KB pagesize

[LTP] [PATCH v1] memcontrol03: Bind to single CPU on systems with 64KB pagesize

[Wei Gao via ltp]

On multi-CPU systems with 64KB page size (e.g. ppc64le), memcontrol03
intermittently fails with over-reclaim of protected pagecache under
trunk_B:

  memcontrol03.c:104: TINFO: Child 142113 in trunk_G: Allocating anon: 150994944
  memcontrol03.c:121: TPASS: Child 142113 exited
  memcontrol03.c:214: TPASS: Expect: (A/B memory.current=54394880) ~= 52428800
  ...
  memcontrol03.c:104: TINFO: Child 142114 in trunk_G: Allocating anon: 174063616
  memcontrol03.c:116: TPASS: Child 142114 killed by OOM
  memcontrol03.c:230: TFAIL: Expect: (A/B memory.current=43319296) ~= 52428800

In the kernel, per-CPU charge batching (MEMCG_CHARGE_BATCH = 64 pages)
caches up to 64 * 64KB = 4MB per CPU in memcg_stock. On a multi-CPU
system, allocating memory across CPUs allows cached stock charges to
accumulate in ancestor trunk_A (up to 4MB * nr_cpus, e.g. 16MB on a
4-CPU machine). Because trunk_A has memory.max = 200M, this extra stock
pressure forces the reclaimer to evict pagecache in trunk_B down to
~35-43MB instead of the expected ~50MB. Simply enlarging the tolerance
rate further is not good idea.

Bind the test process to a single CPU in setup() when page size is
>= 64KB. This confines stock batching to a single CPU, preventing
multi-CPU stock inflation and ensuring reproducible reclaim behavior.

Signed-off-by: Wei Gao <wegao@suse.com>
---
 .../kernel/controllers/memcg/memcontrol03.c    | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/testcases/kernel/controllers/memcg/memcontrol03.c b/testcases/kernel/controllers/memcg/memcontrol03.c
index 96224c4ee..6007d5588 100644
--- a/testcases/kernel/controllers/memcg/memcontrol03.c
+++ b/testcases/kernel/controllers/memcg/memcontrol03.c
@@ -235,6 +235,23 @@ static void test_memcg_min(void)
 	SAFE_UNLINK(TMPDIR"/tmpfile");
 }
 
+static void setup(void)
+{
+	if (getpagesize() >= 64 * 1024) {
+		cpu_set_t mask;
+		int cpu = sched_getcpu();
+
+		if (cpu < 0)
+			tst_brk(TBROK | TERRNO, "sched_getcpu() failed");
+
+		tst_res(TINFO, "Page size >= 64KB, binding to CPU %d", cpu);
+		CPU_ZERO(&mask);
+		CPU_SET(cpu, &mask);
+		if (sched_setaffinity(0, sizeof(mask), &mask))
+			tst_brk(TBROK | TERRNO, "sched_setaffinity() failed");
+	}
+}
+
 static void cleanup(void)
 {
 	cleanup_sub_groups();
@@ -243,6 +260,7 @@ static void cleanup(void)
 }
 
 static struct tst_test test = {
+	.setup = setup,
 	.cleanup = cleanup,
 	.test_all = test_memcg_min,
 	.mount_device = 1,
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] memcontrol03: Bind to single CPU on systems with 64KB pagesize

[linuxtestproject.agent]

Hi Wei,

On Tue Sep 29 02:23:32 2026 +0000, Wei Gao wrote:
> memcontrol03: Bind to single CPU on systems with 64KB pagesize

> diff --git a/testcases/kernel/controllers/memcg/memcontrol03.c b/testcases/kernel/controllers/memcg/memcontrol03.c
> index 96224c4ee..6007d5588 100644
> --- a/testcases/kernel/controllers/memcg/memcontrol03.c
> +++ b/testcases/kernel/controllers/memcg/memcontrol03.c
> @@ -235,6 +235,23 @@ static void test_memcg_min(void)
>  	SAFE_UNLINK(TMPDIR"/tmpfile");
>  }
>  
> +static void setup(void)
> +{

Add #include <sched.h> to memcontrol03.c. The test relies on transitive
inclusion for sched_getcpu(), sched_setaffinity(), and cpu_set_t.

> +	if (getpagesize() >= 64 * 1024) {

Use SAFE_SYSCONF(_SC_PAGESIZE) instead of getpagesize(). The latter is a
legacy API removed in POSIX.1-2001, and memcontrol_common.h already uses
SAFE_SYSCONF(_SC_PAGESIZE).

> +		cpu_set_t mask;
> +		int cpu = sched_getcpu();
> +
> +		if (cpu < 0)
> +			tst_brk(TBROK | TERRNO, "sched_getcpu() failed");
> +
> +		tst_res(TINFO, "Page size >= 64KB, binding to CPU %d", cpu);
> +		CPU_ZERO(&mask);
> +		CPU_SET(cpu, &mask);
> +		if (sched_setaffinity(0, sizeof(mask), &mask))
> +			tst_brk(TBROK | TERRNO, "sched_setaffinity() failed");

On systems with CPU IDs >= 1024 (e.g. large ppc64le systems where
CONFIG_NR_CPUS can be up to 8192), cpu_set_t cannot represent cpu.
CPU_SET() will silently drop the bit, leaving mask empty and causing
sched_setaffinity() to fail with EINVAL. Allocate the mask dynamically
using CPU_ALLOC() or verify cpu < CPU_SETSIZE. Also, check the return
value of sched_setaffinity() with < 0.

Verdict - Needs revision

Pre-existing issues:
- Line 194: sleep(1) is used in a retry loop; use exponential backoff
  polling instead of fixed sleep (Ground Rule 2).
- Lines 166 and 235: string concatenation without spaces (TMPDIR"/tmpfile").

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] memcontrol03: Bind to single CPU on systems with 64KB pagesize

[Michal Koutný via ltp]

Hi.

On Tue, Sep 29, 2026 at 02:23:32AM +0000, Wei Gao <wegao@suse.com> wrote:
> On multi-CPU systems with 64KB page size (e.g. ppc64le), memcontrol03
> intermittently fails with over-reclaim of protected pagecache under
> trunk_B:
> 
>   memcontrol03.c:104: TINFO: Child 142113 in trunk_G: Allocating anon: 150994944
>   memcontrol03.c:121: TPASS: Child 142113 exited
>   memcontrol03.c:214: TPASS: Expect: (A/B memory.current=54394880) ~= 52428800
>   ...
>   memcontrol03.c:104: TINFO: Child 142114 in trunk_G: Allocating anon: 174063616
>   memcontrol03.c:116: TPASS: Child 142114 killed by OOM
>   memcontrol03.c:230: TFAIL: Expect: (A/B memory.current=43319296) ~= 52428800
> 
> In the kernel, per-CPU charge batching (MEMCG_CHARGE_BATCH = 64 pages)
> caches up to 64 * 64KB = 4MB per CPU in memcg_stock. On a multi-CPU
> system, allocating memory across CPUs allows cached stock charges to
> accumulate in ancestor trunk_A (up to 4MB * nr_cpus, e.g. 16MB on a
> 4-CPU machine). Because trunk_A has memory.max = 200M, this extra stock
> pressure forces the reclaimer to evict pagecache in trunk_B down to
> ~35-43MB instead of the expected ~50MB. Simply enlarging the tolerance
> rate further is not good idea.
> 
> Bind the test process to a single CPU in setup() when page size is
> >= 64KB. This confines stock batching to a single CPU, preventing
> multi-CPU stock inflation and ensuring reproducible reclaim behavior.

Should the goal be stability/repeatibility of the test.
What about pinning to the single CPU regardless of page size?

Thanks,
Michal

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v2 0/2] memcontrol03, memcontrol04: Bind test process to a single CPU

[Wei Gao via ltp]

v1->v2:
- pinning to the single CPU regardless of page size base Michal's feedback
on v1

Wei Gao (2):
  memcontrol: Add bind_to_current_cpu() helper
  memcontrol03, memcontrol04: Bind test process to a single CPU

 .../kernel/controllers/memcg/memcontrol03.c   |  1 +
 .../kernel/controllers/memcg/memcontrol04.c   |  1 +
 .../controllers/memcg/memcontrol_common.h     | 27 +++++++++++++++++++
 3 files changed, 29 insertions(+)

-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v2 1/2] memcontrol: Add bind_to_current_cpu() helper

[Wei Gao via ltp]

Add bind_to_current_cpu() to memcontrol_common.h to allow memcg tests
to bind the test process to a single CPU.

Signed-off-by: Wei Gao <wegao@suse.com>
---
 .../controllers/memcg/memcontrol_common.h     | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/testcases/kernel/controllers/memcg/memcontrol_common.h b/testcases/kernel/controllers/memcg/memcontrol_common.h
index 495f924a0..0f5021c0d 100644
--- a/testcases/kernel/controllers/memcg/memcontrol_common.h
+++ b/testcases/kernel/controllers/memcg/memcontrol_common.h
@@ -52,4 +52,31 @@ static inline void alloc_anon(const size_t size)
 	free(buf);
 }
 
+static inline void bind_to_current_cpu(void)
+{
+	int cpu = sched_getcpu();
+	size_t mask_size;
+	cpu_set_t *mask;
+
+	if (cpu < 0)
+		tst_brk(TBROK | TERRNO, "sched_getcpu() failed");
+
+	tst_res(TINFO, "Binding test process to CPU %d", cpu);
+
+	mask = CPU_ALLOC(cpu + 1);
+	if (!mask)
+		tst_brk(TBROK | TERRNO, "CPU_ALLOC() failed");
+
+	mask_size = CPU_ALLOC_SIZE(cpu + 1);
+	CPU_ZERO_S(mask_size, mask);
+	CPU_SET_S(cpu, mask_size, mask);
+
+	if (sched_setaffinity(0, mask_size, mask) < 0) {
+		CPU_FREE(mask);
+		tst_brk(TBROK | TERRNO, "sched_setaffinity() failed");
+	}
+
+	CPU_FREE(mask);
+}
+
 #endif /* MEMCONTROL_COMMON_H__ */
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] memcontrol: Add bind_to_current_cpu() helper

[linuxtestproject.agent]

Hi Wei,

On Wed Sep 30 03:53:14 2026 +0000, Wei Gao via ltp wrote:
> memcontrol: Add bind_to_current_cpu() helper

--- [PATCH 1/2] ---

> Add bind_to_current_cpu() to memcontrol_common.h to allow memcg tests
> to bind the test process to a single CPU.

The commit message only restates what changed. Explain why memcg tests
need to bind to a single CPU (e.g. to prevent multi-CPU per-CPU memcg stock
charge accumulation from causing reclaim variance in hierarchical tests).

> +static inline void bind_to_current_cpu(void)
> +{
> +	int cpu = sched_getcpu();
> +	size_t mask_size;
> +	cpu_set_t *mask;

Include <sched.h> in memcontrol_common.h. The function uses sched_getcpu(),
cpu_set_t, CPU_ALLOC(), and sched_setaffinity(), but currently relies on
indirect inclusion via tst_test.h.

Verdict - Needs revision

Pre-existing issues:
- memcontrol03.c:209: sleep(1) is used in a polling loop. Polling loops
  should use exponential backoff or checkpoint synchronization.
- memcontrol03.c:241, memcontrol04.c:240: fd validity is checked with
  fd > -1 instead of the LTP convention fd != -1.

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] memcontrol: Add bind_to_current_cpu() helper

[Wei Gao via ltp]

On Wed, Sep 30, 2026 at 08:11:14AM +0000, linuxtestproject.agent@gmail.com wrote:
> Hi Wei,
> 
> On Wed Sep 30 03:53:14 2026 +0000, Wei Gao via ltp wrote:
> > memcontrol: Add bind_to_current_cpu() helper
> 
> --- [PATCH 1/2] ---
> 
> > Add bind_to_current_cpu() to memcontrol_common.h to allow memcg tests
> > to bind the test process to a single CPU.
> 
> The commit message only restates what changed. Explain why memcg tests
> need to bind to a single CPU (e.g. to prevent multi-CPU per-CPU memcg stock
> charge accumulation from causing reclaim variance in hierarchical tests).
> 
The reason is in PATCH 2/2.

> > +static inline void bind_to_current_cpu(void)
> > +{
> > +	int cpu = sched_getcpu();
> > +	size_t mask_size;
> > +	cpu_set_t *mask;
> 
> Include <sched.h> in memcontrol_common.h. The function uses sched_getcpu(),
> cpu_set_t, CPU_ALLOC(), and sched_setaffinity(), but currently relies on
> indirect inclusion via tst_test.h.
@Andrea Maybe we need update AI rules? 
> 
> Verdict - Needs revision
> 
> Pre-existing issues:
> - memcontrol03.c:209: sleep(1) is used in a polling loop. Polling loops
>   should use exponential backoff or checkpoint synchronization.
> - memcontrol03.c:241, memcontrol04.c:240: fd validity is checked with
>   fd > -1 instead of the LTP convention fd != -1.
> 
> ---
> Note:
> 
> The agent can sometimes produce false positives although often its
> findings are genuine. If you find issues with the review, please
> comment this email or ignore the suggestions.
> 
> Regards,
> LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v2 2/2] memcontrol03, memcontrol04: Bind test process to a single CPU

[Wei Gao via ltp]

On multi-CPU systems, memcontrol03 and memcontrol04 can intermittently
fail with over-reclaim of protected pagecache under trunk_B:

  memcontrol03.c:104: TINFO: Child 142113 in trunk_G: Allocating anon: 150994944
  memcontrol03.c:121: TPASS: Child 142113 exited
  memcontrol03.c:214: TPASS: Expect: (A/B memory.current=54394880) ~= 52428800
  ...
  memcontrol03.c:104: TINFO: Child 142114 in trunk_G: Allocating anon: 174063616
  memcontrol03.c:116: TPASS: Child 142114 killed by OOM
  memcontrol03.c:230: TFAIL: Expect: (A/B memory.current=43319296) ~= 52428800

In the kernel, per-CPU charge batching (MEMCG_CHARGE_BATCH = 64 pages)
caches charges in per-CPU memcg_stock. On multi-CPU systems (especially
with large page sizes like 64KB on ppc64le where each CPU caches up to
4MB), allocating memory across CPUs allows cached stock charges to
accumulate in ancestor trunk_A. Because trunk_A has memory.max = 200M,
this extra stock pressure forces the reclaimer to evict pagecache in
trunk_B down to ~35-43MB instead of the expected ~50MB.

Set .setup = bind_to_current_cpu in both tests. Since child processes
inherit CPU affinity on fork(), this confines stock batching to a
single CPU across all test children, preventing multi-CPU stock
accumulation and ensuring reproducible reclaim behavior.

Signed-off-by: Wei Gao <wegao@suse.com>
---
 testcases/kernel/controllers/memcg/memcontrol03.c | 1 +
 testcases/kernel/controllers/memcg/memcontrol04.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/testcases/kernel/controllers/memcg/memcontrol03.c b/testcases/kernel/controllers/memcg/memcontrol03.c
index 96224c4ee..d65c03c0d 100644
--- a/testcases/kernel/controllers/memcg/memcontrol03.c
+++ b/testcases/kernel/controllers/memcg/memcontrol03.c
@@ -243,6 +243,7 @@ static void cleanup(void)
 }
 
 static struct tst_test test = {
+	.setup = bind_to_current_cpu,
 	.cleanup = cleanup,
 	.test_all = test_memcg_min,
 	.mount_device = 1,
diff --git a/testcases/kernel/controllers/memcg/memcontrol04.c b/testcases/kernel/controllers/memcg/memcontrol04.c
index 22ca1df8c..28ceaf8c1 100644
--- a/testcases/kernel/controllers/memcg/memcontrol04.c
+++ b/testcases/kernel/controllers/memcg/memcontrol04.c
@@ -242,6 +242,7 @@ static void cleanup(void)
 }
 
 static struct tst_test test = {
+	.setup = bind_to_current_cpu,
 	.cleanup = cleanup,
 	.test_all = test_memcg_low,
 	.mount_device = 1,
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] memcontrol03: Bind to single CPU on systems with 64KB pagesize

[Wei Gao via ltp]

On Tue, Sep 29, 2026 at 06:58:26PM +0200, Michal Koutný wrote:
> Hi.
> 
> On Tue, Sep 29, 2026 at 02:23:32AM +0000, Wei Gao <wegao@suse.com> wrote:
> > On multi-CPU systems with 64KB page size (e.g. ppc64le), memcontrol03
> > intermittently fails with over-reclaim of protected pagecache under
> > trunk_B:
> > 
> >   memcontrol03.c:104: TINFO: Child 142113 in trunk_G: Allocating anon: 150994944
> >   memcontrol03.c:121: TPASS: Child 142113 exited
> >   memcontrol03.c:214: TPASS: Expect: (A/B memory.current=54394880) ~= 52428800
> >   ...
> >   memcontrol03.c:104: TINFO: Child 142114 in trunk_G: Allocating anon: 174063616
> >   memcontrol03.c:116: TPASS: Child 142114 killed by OOM
> >   memcontrol03.c:230: TFAIL: Expect: (A/B memory.current=43319296) ~= 52428800
> > 
> > In the kernel, per-CPU charge batching (MEMCG_CHARGE_BATCH = 64 pages)
> > caches up to 64 * 64KB = 4MB per CPU in memcg_stock. On a multi-CPU
> > system, allocating memory across CPUs allows cached stock charges to
> > accumulate in ancestor trunk_A (up to 4MB * nr_cpus, e.g. 16MB on a
> > 4-CPU machine). Because trunk_A has memory.max = 200M, this extra stock
> > pressure forces the reclaimer to evict pagecache in trunk_B down to
> > ~35-43MB instead of the expected ~50MB. Simply enlarging the tolerance
> > rate further is not good idea.
> > 
> > Bind the test process to a single CPU in setup() when page size is
> > >= 64KB. This confines stock batching to a single CPU, preventing
> > multi-CPU stock inflation and ensuring reproducible reclaim behavior.
> 
> Should the goal be stability/repeatibility of the test.
> What about pinning to the single CPU regardless of page size?
Thanks for quick feedback, v2 sent.
> 
> Thanks,
> Michal



-- 
Mailing list info: https://lists.linux.it/listinfo/ltp