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

[Wei Gao]

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