On Wed 13-05-15 18:29:13, Nikolay Borisov wrote: > Hello, > > I'm running the ltp version 20150420 and stock kernel 4.0 and I've > observed that the memcg_function test is failing. Here is a relevant > snipped from the log: > > > memcg_function_test 14 TFAIL : ltpapicmd.c:190: process 5827 is not > killed > /opt/ltp/testcases/bin/memcg_lib.sh: line 210: 5843 Killed > $TEST_PATH/memcg_process $2 -s $3 > memcg_function_test 15 TPASS : process 5843 is killed > /opt/ltp/testcases/bin/memcg_lib.sh: line 210: 5859 Killed > $TEST_PATH/memcg_process $2 -s $3 > memcg_function_test 16 TPASS : process 5859 is killed > /opt/ltp/testcases/bin/memcg_lib.sh: line 210: 5877 Killed > $TEST_PATH/memcg_process $2 -s $3 > memcg_function_test 17 TPASS : process 5877 is killed > /opt/ltp/testcases/bin/memcg_lib.sh: line 210: 5894 Killed > $TEST_PATH/memcg_process $2 -s $3 > memcg_function_test 18 TPASS : process 5894 is killed > /opt/ltp/testcases/bin/memcg_lib.sh: line 210: 5911 Killed > $TEST_PATH/memcg_process $2 -s $3 > memcg_function_test 19 TPASS : process 5911 is killed > /opt/ltp/testcases/bin/memcg_lib.sh: line 210: 5927 Killed > $TEST_PATH/memcg_process $2 -s $3 > memcg_function_test 20 TPASS : process 5927 is killed > /opt/ltp/testcases/bin/memcg_lib.sh: line 210: 5942 Killed > $TEST_PATH/memcg_process $2 -s $3 > memcg_function_test 21 TPASS : process 5942 is killed > memcg_function_test 22 TFAIL : ltpapicmd.c:190: input=4095, > limit_in_bytes=0 > memcg_function_test 23 TFAIL : ltpapicmd.c:190: input=4097, > limit_in_bytes=4096 > memcg_function_test 24 TFAIL : ltpapicmd.c:190: input=1, > limit_in_bytes=0 > memcg_function_test 25 TPASS : return value is 0 > memcg_function_test 26 TPASS : return value is 1 > memcg_function_test 27 TPASS : return value is 1 > memcg_function_test 28 TPASS : return value is 1 > memcg_function_test 29 TPASS : force memory succeeded > memcg_function_test 30 TFAIL : ltpapicmd.c:190: force memory should > fail > memcg_function_test 31 TPASS : return value is 0 > memcg_function_test 32 TPASS : return value is 0 > memcg_function_test 33 TPASS : return value is 0 > memcg_function_test 34 TPASS : return value is 0 > memcg_function_test 35 TPASS : return value is 1 > Running /opt/ltp/testcases/bin/memcg_process --mmap-anon -s 4096 > Warming up for test: 36, pid: 6128 > Process is still here after warm up: 6128 > memcg_function_test 36 TPASS : rss=4096/4096 > memcg_function_test 36 TPASS : rss=0/0 > Running /opt/ltp/testcases/bin/memcg_process --mmap-anon -s 4096 > Warming up for test: 37, pid: 6155 > Process is still here after warm up: 6155 > memcg_function_test 37 TPASS : rss=4096/4096 > memcg_function_test 37 TPASS : rss=0/0 > Running /opt/ltp/testcases/bin/memcg_process --mmap-anon -s 4096 > Warming up for test: 38, pid: 6182 > Process is still here after warm up: 6182 > memcg_function_test 38 TPASS : rss=4096/4096 > memcg_function_test 38 TPASS : rss=0/0 > <<<execution_status>>> > initiation_status="ok" > duration=135 termination_type=exited termination_id=5 corefile=no > cutime=8 cstime=15 > <<<test_end>>> > INFO: ltp-pan reported some tests FAIL > LTP Version: 20150420 > > According to the file at : > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/controllers/memcg/functional/memcg_function_test.sh > > > The failing test cases 14, 22, 23, 24 and 30 test respectively: > > 14: Hogging memory like so: mmap(NULL, memsize, PROT_WRITE | PROT_READ, > MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0, 0); MAP_LOCKED will not trigger the OOM killer as explained http://marc.info/?l=linux-mm&m=142122902313315&w=2. So this is expected and Cyril is working on fixing the test case. > # Case 22 - 24: Test limit_in_bytes will be aligned to PAGESIZE - The > output clearly indicates that the limits in bytes is not being page > aligned? I can see > memcg_function_test 22 TFAIL : ltpapicmd.c:190: input=4095, > limit_in_bytes=0 > memcg_function_test 23 TFAIL : ltpapicmd.c:190: input=4097, > limit_in_bytes=4096 > memcg_function_test 24 TFAIL : ltpapicmd.c:190: input=1, > limit_in_bytes=0 So limit_in_bytes _is_ page aligned but we round down rather than up. > Is this desired behavior, in which case ltp is broken or is it > a genuine bug? This behavior has changed by 3e32cb2e0a12 ("mm: memcontrol: lockless page counters") introduced in 3.19. The change in rounding has been pointed out during the review http://marc.info/?l=linux-mm&m=141207518827336&w=2 but the conclusion was that the original round up wasn't really much better http://marc.info/?l=linux-mm&m=141226210316376&w=2 resp. http://marc.info/?l=linux-mm&m=141234785111200&w=2 I will post fix for ltp in the reply > 30: Again, it locks memory with mmap and then tries to see if > force_empty would succeed. Expecting it to fail, but in this particular > case it succeeds? I am not sure I understand this testcase. It does: TEST_PATH/memcg_process --mmap-anon -s $PAGESIZE [...] echo 1 > memory.force_empty 2> /dev/null if [ $? -ne 0 ]; then result $PASS "force memory failed as expected" else result $FAIL "force memory should fail" fi and that means: void mmap_anon() { static char *p; if (!flag_allocated) { p = mmap(NULL, memsize, PROT_WRITE | PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); if (p == MAP_FAILED) err(1, "mmap(anonymous) failed"); touch_memory(p, memsize); } else { if (munmap(p, memsize) == -1) err(1, "munmap(anonymous) failed"); } } so there is no mlock there. Why should the force reclaim fail then? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>