From: Nikolay Borisov <kernel@kyup.com>
To: cgroups@vger.kernel.org
Cc: hannes@cmpxchg.org, mhocko@suse.cz, linux-mm@kvack.org
Subject: Possible bug - LTP failure for memcg
Date: Wed, 13 May 2015 18:29:13 +0300 [thread overview]
Message-ID: <55536DC9.90200@kyup.com> (raw)
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);
# 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? Is this desired behavior, in which case ltp is broken or is it
a genuine bug?
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?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2015-05-13 15:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 15:29 Nikolay Borisov [this message]
2015-05-14 9:21 ` Possible bug - LTP failure for memcg Michal Hocko
[not found] ` <20150514092145.GA6799-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-05-14 9:23 ` Michal Hocko
2015-05-14 9:23 ` Michal Hocko
2015-05-14 10:35 ` Cyril Hrubis
2015-05-14 11:31 ` Michal Hocko
[not found] ` <20150514113101.GD6799-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-05-14 12:36 ` Cyril Hrubis
2015-05-14 12:36 ` Cyril Hrubis
2015-05-14 10:31 ` Cyril Hrubis
2015-05-14 10:31 ` Cyril Hrubis
[not found] ` <20150514103148.GA5066-J5syqNJeCN4b1SvskN2V4Q@public.gmane.org>
2015-05-14 11:56 ` Michal Hocko
2015-05-14 11:56 ` Michal Hocko
[not found] ` <20150514115641.GE6799-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-05-14 12:01 ` Cyril Hrubis
2015-05-14 12:01 ` Cyril Hrubis
[not found] ` <20150514120142.GG5066-J5syqNJeCN4b1SvskN2V4Q@public.gmane.org>
2015-05-14 12:12 ` Michal Hocko
2015-05-14 12:12 ` Michal Hocko
2015-05-14 12:38 ` Cyril Hrubis
2015-05-14 14:30 ` Michal Hocko
2015-05-14 14:30 ` Michal Hocko
[not found] ` <20150514143039.GI6799-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-05-14 14:44 ` Cyril Hrubis
2015-05-14 14:44 ` Cyril Hrubis
2015-05-14 14:49 ` Michal Hocko
2015-05-14 14:49 ` Michal Hocko
[not found] ` <20150514144949.GJ6799-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-05-14 15:27 ` Cyril Hrubis
2015-05-14 15:27 ` Cyril Hrubis
[not found] ` <55536DC9.90200-6AxghH7DbtA@public.gmane.org>
2015-05-14 12:09 ` Michal Hocko
2015-05-14 12:09 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55536DC9.90200@kyup.com \
--to=kernel@kyup.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.