[LTP] [PATCH] memcontrol03: Account for process size in cgroup allocation

[ALOK TIWARI]

On 09-05-2025 20:11, Martin Doucha wrote:
> On 09. 05. 25 16:11, Michal Koutný wrote:
>> On Fri, May 09, 2025 at 12:01:47PM +0200, Cyril Hrubis 
>> <chrubis@suse.cz> wrote:
>>>> Unfortunately, we can't. I've tested this and memory.current can change
>>>> a lot during the first process migration.
>>>
>>> That does sound strange. @Michal any idea what happens here?
>>
>> [Process migrates itself (echo 0 >$target_cg/cgroup.procs) or] it's
>> otherwise active during the migration?
>>
>> (Also, the apparent increase of memory.current may be amplified because
>> of MEMCG_CHARGE_BATCH even with initially small allocation.)
> 
> The process migrates itself:
> SAFE_CG_PRINTF(cg, "cgroup.procs", "%d", getpid());
> 
> We're dealing with an issue where the test has 2MB safety margin from 
> triggering OOM but immediately after the process migrates itself into 
> the cgroup on PPC64LE, memory.current will be ~4MB and the process will 
> randomly trigger OOM anyway. So we're increasing the safety margin by 
> whatever memory.current says immediately after the migration.
> 


Error log without this commit:
===============================================================
I was seeing error on 64K image aarch64 (failure can occur randomly):
tst_test.c:1875: TINFO: === Testing on ext4 ===
tst_test.c:1209: TINFO: Formatting /dev/loop0 with ext4 opts='' extra 
opts=''
mke2fs 1.47.1 (20-May-2024)
tst_test.c:1221: TINFO: Mounting /dev/loop0 to 
/tmpdir/ltp-Cw5kgjUp5v/LTP_memW9rz73/mntdir fstyp=ext4 flags=0
memcontrol03.c:142: TINFO: Child 28192 in leaf_C: Allocating pagecache: 
52428800
memcontrol03.c:142: TINFO: Child 28193 in leaf_D: Allocating pagecache: 
52428800
memcontrol03.c:142: TINFO: Child 28194 in leaf_F: Allocating pagecache: 
52428800
memcontrol03.c:105: TINFO: Child 28195 in trunk_G: Allocating anon: 
155189248
memcontrol03.c:119: TPASS: Child 28195 exited
memcontrol03.c:206: TPASS: Expect: (A/B memory.current=49217536) ~= 52428800
memcontrol03.c:212: TFAIL: Expect: (A/B/C memory.current=21168128) ~= 
34603008
memcontrol03.c:214: TPASS: Expect: (A/B/D memory.current=25624576) ~= 
17825792
memcontrol03.c:216: TPASS: Expect: (A/B/E memory.current=0) ~= 0
memcontrol03.c:105: TINFO: Child 28196 in trunk_G: Allocating anon: 
178257920
memcontrol03.c:114: TPASS: Child 28196 killed by OOM
memcontrol03.c:222: TPASS: Expect: (A/B memory.current=49217536) ~= 52428800

Summary:
passed   34
failed   1
broken   0
skipped  0
warnings 0
<<<execution_status>>>

LTP test PASSED with commit:
===============================================================
here my observation for arrch64 64K page Image with this commit:

tst_test.c:1875: TINFO: === Testing on ext4 ===
tst_test.c:1209: TINFO: Formatting /dev/loop0 with ext4 opts='' extra 
opts=''
mke2fs 1.47.1 (20-May-2024)
tst_test.c:1221: TINFO: Mounting /dev/loop0 to /tmp/LTP_mem5Qmtgc/mntdir 
fstyp=ext4 flags=0
memcontrol03.c:151: TINFO: Child 28367 in leaf_C: Allocating pagecache: 
48234496
memcontrol03.c:151: TINFO: Child 28368 in leaf_D: Allocating pagecache: 
48234496
memcontrol03.c:151: TINFO: Child 28369 in leaf_F: Allocating pagecache: 
48234496
memcontrol03.c:108: TINFO: Child 28370 in trunk_G: Allocating anon: 
150994944
memcontrol03.c:125: TPASS: Child 28370 exited
memcontrol03.c:218: TPASS: Expect: (A/B memory.current=54132736) ~= 52428800
memcontrol03.c:224: TPASS: Expect: (A/B/C memory.current=21299200) ~= 
34603008
memcontrol03.c:226: TPASS: Expect: (A/B/D memory.current=25690112) ~= 
17825792
memcontrol03.c:228: TPASS: Expect: (A/B/E memory.current=0) ~= 0
memcontrol03.c:108: TINFO: Child 28371 in trunk_G: Allocating anon: 
173998080
memcontrol03.c:120: TPASS: Child 28371 killed by OOM
memcontrol03.c:234: TPASS: Expect: (A/B memory.current=49479680) ~= 52428800

Summary:
passed   35
failed   0
broken   0
skipped  0
warnings 0
--------------------------------

Is there any case where this LTP test depends on the upstream commit 
1bc542c6a0d ('mm/vmscan: wake up flushers conditionally to avoid cgroup 
OOM')?


Thanks,
Alok