Although there is supposed to be a periodic and asynchronous flush of stats every 2 seconds, the actual time lag between succesive runs can actually vary quite a bit. In fact, I have seen time lag of up to 10s of seconds in some cases.
At the end of test_memcg_sock, it waits up to 3 seconds for the "sock" attribute of memory.stat to go back down to 0. Obviously it may occasionally fail especially when the kernel has large page size (e.g. 64k). Treat this failure as an expected failure (XFAIL) to distinguish it from the other failure cases. Signed-off-by: Waiman Long <[email protected]> --- tools/testing/selftests/cgroup/test_memcontrol.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testing/selftests/cgroup/test_memcontrol.c index 0ef09bafa68c..9206da51ac83 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -1486,12 +1486,20 @@ static int test_memcg_sock(const char *root) * Poll memory.stat for up to 3 seconds (~FLUSH_TIME plus some * scheduling slack) and require that the "sock " counter * eventually drops to zero. + * + * The actual run-to-run elapse time between consecutive run + * of asynchronous memcg rstat flush may varies quite a bit. + * So the 3 seconds wait time may not be enough for the "sock" + * counter to go down to 0. Treat it as a XFAIL instead of + * a FAIL. */ sock_post = cg_read_key_long_poll(memcg, "memory.stat", "sock ", 0, MEMCG_SOCKSTAT_WAIT_RETRIES, DEFAULT_WAIT_INTERVAL_US); - if (sock_post) + if (sock_post) { + ret = KSFT_XFAIL; goto cleanup; + } ret = KSFT_PASS; @@ -1753,6 +1761,9 @@ int main(int argc, char **argv) case KSFT_SKIP: ksft_test_result_skip("%s\n", tests[i].name); break; + case KSFT_XFAIL: + ksft_test_result_xfail("%s\n", tests[i].name); + break; default: ksft_test_result_fail("%s\n", tests[i].name); break; -- 2.53.0
