From: Li Wang <li.wang@linux.dev>
To: Andrea Cervesato <andrea.cervesato@suse.com>,
Xuewen Wang <wangxuewen@kylinos.cn>
Cc: ltp@lists.linux.it, linuxtestproject.agent@gmail.com
Subject: Re: [LTP] memcg/functional: fix memcg_failcnt intermittent timeout by disabling swap
Date: Fri, 7 Aug 2026 14:20:23 +0800 [thread overview]
Message-ID: <anV5J8HZ-agTZpAB@linux.dev> (raw)
In-Reply-To: <6a756e7a.cc089686.309364.c33e@mx.google.com>
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
next prev parent reply other threads:[~2026-08-07 6:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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=anV5J8HZ-agTZpAB@linux.dev \
--to=li.wang@linux.dev \
--cc=andrea.cervesato@suse.com \
--cc=linuxtestproject.agent@gmail.com \
--cc=ltp@lists.linux.it \
--cc=wangxuewen@kylinos.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox