* [LTP] [PATCH v3] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
@ 2026-08-07 1:44 Xuewen Wang
2026-08-07 2:51 ` [LTP] " linuxtestproject.agent
2026-08-07 3:28 ` [LTP] [PATCH v3] " Li Wang
0 siblings, 2 replies; 9+ messages in thread
From: Xuewen Wang @ 2026-08-07 1:44 UTC (permalink / raw)
To: ltp; +Cc: Xuewen Wang
memcg_failcnt.sh tests the memory.failcnt counter by allocating
reclaimable memory (mmap-anon/mmap-file/shm) beyond a tiny cgroup
limit (1 page). It relies on the process being OOM-killed so that
signal_memcg_process()'s wait loop exits.
With swap enabled the kernel usually still OOM-kills the process,
but on arm64 reclaim (swap out) sometimes succeeds instead:
usage_in_bytes stays at the limit and the process keeps running,
so the wait loop times out (TBROK) intermittently.
Example failure on arm64 (kernel 6.6):
memcg_failcnt 2 TBROK: timed out on memory.usage_in_bytes 4096 0 8192
Disable swap around the allocation and re-enable it afterwards,
mirroring what memcg_limit_in_bytes.sh already does for the same
reclaimable memory types.
Signed-off-by: Xuewen Wang <wangxuewen@kylinos.cn>
---
Changes in v2:
- Drop "2>/dev/null" from swapoff/swapon so that a failure to disable
swap (or a missing swapoff binary) stays visible, instead of silently
letting the intermittent timeout recur. Per the LTP AI review, the
redirect hid the very error this fix relies on, and
memcg_limit_in_bytes.sh does not redirect stderr either.
Changes in v3:
- Move swapoff to do_setup() and swapon to do_cleanup() per Li Wang,
instead of wrapping each test iteration with swapoff/swapon in do_test().
---
.../controllers/memcg/functional/memcg_failcnt.sh | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh b/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
index 3a02d16c2..93e8d4838 100755
--- a/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
+++ b/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
@@ -11,6 +11,20 @@
MEMCG_TESTFUNC=do_test
MEMCG_SHMMAX=1
TST_TEST_DATA="--mmap-anon --mmap-file --shm"
+TST_SETUP=do_setup
+TST_CLEANUP=do_cleanup
+
+do_setup()
+{
+ memcg_setup
+ swapoff -a
+}
+
+do_cleanup()
+{
+ swapon -a
+ memcg_cleanup
+}
do_test()
{
--
2.25.1
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-08-07 1:44 [LTP] [PATCH v3] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap Xuewen Wang
@ 2026-08-07 2:51 ` linuxtestproject.agent
2026-08-07 3:52 ` Li Wang
2026-08-07 3:28 ` [LTP] [PATCH v3] " Li Wang
1 sibling, 1 reply; 9+ messages in thread
From: linuxtestproject.agent @ 2026-08-07 2:51 UTC (permalink / raw)
To: Xuewen Wang; +Cc: ltp
Hi Xuewen,
On Fri, Aug 7, 2026, Xuewen Wang wrote:
> memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
> +do_setup()
> +{
> + memcg_setup
> + swapoff -a
> +}
Could this use ROD so a failed swapoff aborts the test? swapoff can fail
when there is not enough memory to page the swap contents back in.
_tst_run_iterations() ignores the setup function's return status, so the
test proceeds with swap enabled and the original intermittent timeout
remains.
> +do_cleanup()
> +{
> + swapon -a
> + memcg_cleanup
> +}
Could cleanup restore only swap areas that were active before setup, and
only if swapoff was attempted? TST_DO_CLEANUP is set before do_setup(), so
a TCONF from memcg_setup() reaches this function before swapoff. swapon -a
can then activate previously inactive fstab entries. Conversely, dynamically
managed swap areas absent from fstab are disabled by swapoff -a but are not
restored by swapon -a.
Verdict - Needs revision
---
Note:
The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.
Regards,
LTP AI Reviewer
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-08-07 2:51 ` [LTP] " linuxtestproject.agent
@ 2026-08-07 3:52 ` Li Wang
2026-08-07 5:34 ` Andrea Cervesato via ltp
0 siblings, 1 reply; 9+ messages in thread
From: Li Wang @ 2026-08-07 3:52 UTC (permalink / raw)
To: linuxtestproject.agent; +Cc: Xuewen Wang, ltp
linuxtestproject.agent@gmail.com wrote:
> Hi Xuewen,
>
> On Fri, Aug 7, 2026, Xuewen Wang wrote:
> > memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
>
> > +do_setup()
> > +{
> > + memcg_setup
> > + swapoff -a
> > +}
>
> Could this use ROD so a failed swapoff aborts the test? swapoff can fail
> when there is not enough memory to page the swap contents back in.
> _tst_run_iterations() ignores the setup function's return status, so the
> test proceeds with swap enabled and the original intermittent timeout
> remains.
Fair point that ignoring the return status defeats the purpose. But I'd
rather not TBROK on a swapoff failure, that's an environment limitation,
not a test failure. Especially swapoff here is an enhancement but not
a hard requirement for this test.
>
> > +do_cleanup()
> > +{
> > + swapon -a
> > + memcg_cleanup
> > +}
>
> Could cleanup restore only swap areas that were active before setup, and
> only if swapoff was attempted? TST_DO_CLEANUP is set before do_setup(), so
> a TCONF from memcg_setup() reaches this function before swapoff. swapon -a
> can then activate previously inactive fstab entries. Conversely, dynamically
> managed swap areas absent from fstab are disabled by swapoff -a but are not
> restored by swapon -a.
That is a bit over-engineering.
If an inactive fstab entry gets activated by swapon -a, that arguably
points to a misconfigured test host rather than something this test
should work around.
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-08-07 3:52 ` Li Wang
@ 2026-08-07 5:34 ` Andrea Cervesato via ltp
2026-08-07 6:20 ` Li Wang
0 siblings, 1 reply; 9+ messages in thread
From: Andrea Cervesato via ltp @ 2026-08-07 5:34 UTC (permalink / raw)
To: Li Wang; +Cc: Xuewen Wang, ltp, linuxtestproject.agent
Hi Li,
> Fair point that ignoring the return status defeats the purpose. But I'd
> rather not TBROK on a swapoff failure, that's an environment limitation,
> not a test failure. Especially swapoff here is an enhancement but not
> a hard requirement for this test.
I agree.
> That is a bit over-engineering.
>
> If an inactive fstab entry gets activated by swapon -a, that arguably
> points to a misconfigured test host rather than something this test
> should work around.
And also here. Unfortunately we don't have enough data for shell tests,
so AI agent is not really working well in there..
Honestly I don't know how to fix this but adding more examples which
we don't have..
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-08-07 5:34 ` Andrea Cervesato via ltp
@ 2026-08-07 6:20 ` Li Wang
0 siblings, 0 replies; 9+ messages in thread
From: Li Wang @ 2026-08-07 6:20 UTC (permalink / raw)
To: Andrea Cervesato, Xuewen Wang; +Cc: ltp, linuxtestproject.agent
Hi Xuewen, Andrea,
On Fri, Aug 07, 2026 at 05:34:49AM +0000, Andrea Cervesato wrote:
> Hi Li,
>
> > Fair point that ignoring the return status defeats the purpose. But I'd
> > rather not TBROK on a swapoff failure, that's an environment limitation,
> > not a test failure. Especially swapoff here is an enhancement but not
> > a hard requirement for this test.
>
> I agree.
>
> > That is a bit over-engineering.
> >
> > If an inactive fstab entry gets activated by swapon -a, that arguably
> > points to a misconfigured test host rather than something this test
> > should work around.
>
> And also here. Unfortunately we don't have enough data for shell tests,
> so AI agent is not really working well in there..
>
> Honestly I don't know how to fix this but adding more examples which
> we don't have..
No worries, AI agent being too strict in reviewing is not a bad thing.
It inspires me to think about something maybe in a different way.
Like this patch, I am now thinking if we can just limit it only
inside the cgroup:
--- a/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
+++ b/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
@@ -17,18 +17,17 @@ TST_CLEANUP=do_cleanup
do_setup()
{
memcg_setup
- swapoff -a
}
do_cleanup()
{
- swapon -a
memcg_cleanup
}
do_test()
{
ROD echo $MEMORY_LIMIT \> memory.limit_in_bytes
+ ROD echo 0 \> memory.swappiness
start_memcg_process $2 -s ${MEMORY_TO_ALLOCATE}
ROD echo $MEMCG_PROCESS_PID \> tasks
@Xuewen, can you try this patch and see if it can solve your problem?
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [LTP] [PATCH v3] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-08-07 1:44 [LTP] [PATCH v3] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap Xuewen Wang
2026-08-07 2:51 ` [LTP] " linuxtestproject.agent
@ 2026-08-07 3:28 ` Li Wang
1 sibling, 0 replies; 9+ messages in thread
From: Li Wang @ 2026-08-07 3:28 UTC (permalink / raw)
To: Xuewen Wang; +Cc: ltp
Patch merged, thanks!
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH v2] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
@ 2026-08-05 6:40 Xuewen Wang
2026-08-05 7:40 ` [LTP] " linuxtestproject.agent
0 siblings, 1 reply; 9+ messages in thread
From: Xuewen Wang @ 2026-08-05 6:40 UTC (permalink / raw)
To: ltp; +Cc: liwang, Xuewen Wang, rpalethorpe
memcg_failcnt.sh tests the memory.failcnt counter by allocating
reclaimable memory (mmap-anon/mmap-file/shm) beyond a tiny cgroup
limit (1 page). It relies on the process being OOM-killed so that
signal_memcg_process()'s wait loop exits.
With swap enabled the kernel usually still OOM-kills the process,
but on arm64 reclaim (swap out) sometimes succeeds instead:
usage_in_bytes stays at the limit and the process keeps running,
so the wait loop times out (TBROK) intermittently.
Example failure on arm64 (kernel 6.6):
memcg_failcnt 2 TBROK: timed out on memory.usage_in_bytes 4096 0 8192
Disable swap around the allocation and re-enable it afterwards,
mirroring what memcg_limit_in_bytes.sh already does for the same
reclaimable memory types.
Signed-off-by: Xuewen Wang <wangxuewen@kylinos.cn>
---
Changes in v2:
- Drop "2>/dev/null" from swapoff/swapon so that a failure to disable
swap (or a missing swapoff binary) stays visible, instead of silently
letting the intermittent timeout recur. Per the LTP AI review, the
redirect hid the very error this fix relies on, and
memcg_limit_in_bytes.sh does not redirect stderr either.
---
.../controllers/memcg/functional/memcg_failcnt.sh | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh b/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
index 3a02d16c2..9ac3880f6 100755
--- a/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
+++ b/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
@@ -11,11 +11,20 @@
MEMCG_TESTFUNC=do_test
MEMCG_SHMMAX=1
TST_TEST_DATA="--mmap-anon --mmap-file --shm"
+TST_CLEANUP=do_cleanup
+
+do_cleanup()
+{
+ memcg_cleanup
+ swapon -a
+}
do_test()
{
ROD echo $MEMORY_LIMIT \> memory.limit_in_bytes
+ swapoff -a
+
start_memcg_process $2 -s ${MEMORY_TO_ALLOCATE}
ROD echo $MEMCG_PROCESS_PID \> tasks
@@ -24,6 +33,8 @@ do_test()
stop_memcg_process
+ swapon -a
+
failcnt=$(cat memory.failcnt)
if [ $failcnt -gt 0 ]; then
tst_res TPASS "memory.failcnt is $failcnt, > 0 as expected"
--
2.25.1
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-08-05 6:40 [LTP] [PATCH v2] " Xuewen Wang
@ 2026-08-05 7:40 ` linuxtestproject.agent
0 siblings, 0 replies; 9+ messages in thread
From: linuxtestproject.agent @ 2026-08-05 7:40 UTC (permalink / raw)
To: Xuewen Wang; +Cc: ltp
Hi Xuewen,
On Aug 5, 2026, Xuewen Wang wrote:
> memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
> +TST_CLEANUP=do_cleanup
> +
> +do_cleanup()
> +{
> + memcg_cleanup
> + swapon -a
> +}
Could the test save and restore the initially active swap areas instead?
`swapon -a` does not restore the original state: an active area absent from
fstab, such as zram, remains disabled, while an fstab area that was initially
disabled may be enabled. The cleanup also runs if setup exits before
`swapoff -a`, so that path can enable swap without the test disabling it.
> + swapoff -a
Could `swapon` and `swapoff` be declared in `TST_NEEDS_CMDS`, and could this
invocation abort on failure? A bare command failure is ignored by the shell
library, so a missing command or a failure to move swapped pages back to RAM
allows the allocation to proceed with swap still active and preserves the
timeout this patch is intended to fix. Failures while restoring swap should
also be reported.
Verdict - Needs revision
---
Note:
The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.
Regards,
LTP AI Reviewer
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
@ 2026-07-31 1:49 Xuewen Wang
2026-07-31 2:46 ` [LTP] " linuxtestproject.agent
0 siblings, 1 reply; 9+ messages in thread
From: Xuewen Wang @ 2026-07-31 1:49 UTC (permalink / raw)
To: ltp; +Cc: liwang, Xuewen Wang, rpalethorpe
memcg_failcnt.sh tests the memory.failcnt counter by allocating
reclaimable memory (mmap-anon/mmap-file/shm) beyond a tiny cgroup
limit (1 page). It relies on the process being OOM-killed so that
signal_memcg_process()'s wait loop exits.
With swap enabled the kernel usually still OOM-kills the process,
but on arm64 reclaim (swap out) sometimes succeeds instead:
usage_in_bytes stays at the limit and the process keeps running,
so the wait loop times out (TBROK) intermittently.
Example failure on arm64 (kernel 6.6):
memcg_failcnt 2 TBROK: timed out on memory.usage_in_bytes 4096 0 8192
Disable swap around the allocation and re-enable it afterwards,
mirroring what memcg_limit_in_bytes.sh already does for the same
reclaimable memory types.
Signed-off-by: Xuewen Wang <wangxuewen@kylinos.cn>
---
.../controllers/memcg/functional/memcg_failcnt.sh | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh b/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
index 3a02d16c2..07d913147 100755
--- a/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
+++ b/testcases/kernel/controllers/memcg/functional/memcg_failcnt.sh
@@ -11,11 +11,20 @@
MEMCG_TESTFUNC=do_test
MEMCG_SHMMAX=1
TST_TEST_DATA="--mmap-anon --mmap-file --shm"
+TST_CLEANUP=do_cleanup
+
+do_cleanup()
+{
+ memcg_cleanup
+ swapon -a 2>/dev/null
+}
do_test()
{
ROD echo $MEMORY_LIMIT \> memory.limit_in_bytes
+ swapoff -a 2>/dev/null
+
start_memcg_process $2 -s ${MEMORY_TO_ALLOCATE}
ROD echo $MEMCG_PROCESS_PID \> tasks
@@ -24,6 +33,8 @@ do_test()
stop_memcg_process
+ swapon -a 2>/dev/null
+
failcnt=$(cat memory.failcnt)
if [ $failcnt -gt 0 ]; then
tst_res TPASS "memory.failcnt is $failcnt, > 0 as expected"
--
2.25.1
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-07-31 1:49 [LTP] [PATCH] " Xuewen Wang
@ 2026-07-31 2:46 ` linuxtestproject.agent
2026-08-03 13:38 ` Andrea Cervesato via ltp
0 siblings, 1 reply; 9+ messages in thread
From: linuxtestproject.agent @ 2026-07-31 2:46 UTC (permalink / raw)
To: Xuewen Wang; +Cc: ltp
Hi Xuewen,
On Fri, 31 Jul 2026, Xuewen Wang wrote:
> memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
> + swapoff -a 2>/dev/null
> +
> start_memcg_process $2 -s ${MEMORY_TO_ALLOCATE}
The 2>/dev/null here hides errors from the very command that implements
the fix. If swapoff fails, or the command is not present, swap stays
enabled and the intermittent timeout this patch targets can recur, now
without any diagnostic to explain it.
memcg_limit_in_bytes.sh, cited as the model for this change, runs
swapoff -a and swapon -a without redirecting stderr. Would dropping the
redirect (at least on swapoff) be preferable, so a failure to disable
swap remains visible?
Verdict - Needs revision
---
Note:
The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.
Regards,
LTP AI Reviewer
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
2026-07-31 2:46 ` [LTP] " linuxtestproject.agent
@ 2026-08-03 13:38 ` Andrea Cervesato via ltp
0 siblings, 0 replies; 9+ messages in thread
From: Andrea Cervesato via ltp @ 2026-08-03 13:38 UTC (permalink / raw)
To: linuxtestproject.agent; +Cc: Xuewen Wang, ltp
Hi Xuewen,
> > memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
>
> > + swapoff -a 2>/dev/null
> > +
> > start_memcg_process $2 -s ${MEMORY_TO_ALLOCATE}
>
> The 2>/dev/null here hides errors from the very command that implements
> the fix. If swapoff fails, or the command is not present, swap stays
> enabled and the intermittent timeout this patch targets can recur, now
> without any diagnostic to explain it.
>
> memcg_limit_in_bytes.sh, cited as the model for this change, runs
> swapoff -a and swapon -a without redirecting stderr. Would dropping the
> redirect (at least on swapoff) be preferable, so a failure to disable
> swap remains visible?
This is correct. If swapoff fails, we can't understand why.
Regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-08-07 6:21 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-07 1:44 [LTP] [PATCH v3] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap Xuewen Wang
2026-08-07 2:51 ` [LTP] " linuxtestproject.agent
2026-08-07 3:52 ` Li Wang
2026-08-07 5:34 ` Andrea Cervesato via ltp
2026-08-07 6:20 ` Li Wang
2026-08-07 3:28 ` [LTP] [PATCH v3] " Li Wang
-- strict thread matches above, loose matches on Subject: below --
2026-08-05 6:40 [LTP] [PATCH v2] " Xuewen Wang
2026-08-05 7:40 ` [LTP] " linuxtestproject.agent
2026-07-31 1:49 [LTP] [PATCH] " Xuewen Wang
2026-07-31 2:46 ` [LTP] " linuxtestproject.agent
2026-08-03 13:38 ` Andrea Cervesato via ltp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox