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

["Michal Koutný via ltp" <ltp@lists.linux.it>]

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