[LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Wei Gao via ltp]

Reduce the throttling interval from 2 MB to 64 KB (usleep for 200us
every 64 KB) in the page-dirtying loop. This smooths out allocation
spikes and gives asynchronous swap writeback time to catch up under
slower VM storage environments, avoiding unexpected MemCG OOM-kills.

Signed-off-by: Wei Gao <wegao@suse.com>
---
 testcases/kernel/mem/mmapstress/mmapstress06.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
index 4e6023399..2813ef185 100644
--- a/testcases/kernel/mem/mmapstress/mmapstress06.c
+++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
@@ -57,10 +57,14 @@ static void run_test(void)
 
 		tst_res(TINFO, "Dirtying %zu bytes in child", map_size);
 
+		/*
+		 * Yield periodically to space out allocation spikes and allow
+		 * asynchronous swap writeback to catch up on slower VM disks.
+		 */
 		for (size_t i = 0; i < map_size; i += page_size) {
 			mmapaddr[i] = 'a';
-			if ((i % (2 * 1024 * 1024)) == 0)
-				usleep(1000);
+			if ((i % (64 * 1024)) == 0)
+				usleep(200);
 		}
 
 		SAFE_CG_SCANF(cg_child, "memory.swap.current", "%lu", &cg_swap_after);
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[linuxtestproject.agent]

Hi Wei,

On Tue, Aug 25, 2026, Wei Gao wrote:
> mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

> +		/*
> +		 * Yield periodically to space out allocation spikes and allow
> +		 * asynchronous swap writeback to catch up on slower VM disks.
> +		 */
>  		for (size_t i = 0; i < map_size; i += page_size) {
>  			mmapaddr[i] = 'a';
> -			if ((i % (2 * 1024 * 1024)) == 0)
> -				usleep(1000);
> +			if ((i % (64 * 1024)) == 0)
> +				usleep(200);

Could this avoid using a fixed sleep to synchronize with asynchronous swap
writeback? The 7.2 cgroup documentation says memory.max invokes the cgroup OOM
killer when reclaim cannot reduce usage, while the delay here is unrelated to
actual reclaim progress. A swap device slower than the chosen dirtying rate
can therefore still OOM-kill the child and make the test fail for
environmental timing reasons. Please use reclaim throttling or poll observable
progress with backoff instead of tuning a fixed delay.

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

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Andrea Cervesato via ltp]

Hi Wei,

> Reduce the throttling interval from 2 MB to 64 KB (usleep for 200us
> every 64 KB) in the page-dirtying loop. This smooths out allocation
> spikes and gives asynchronous swap writeback time to catch up under
> slower VM storage environments, avoiding unexpected MemCG OOM-kills.

Unfortunately this is not a solution but a workaround, we need to make
sure that we are able to see any change to the swap memory while
allocating dirty pages close to the memory.max. This is probably a
fix for a specific target rather than complete fix.

We need to find an another way to ensure that OOM killer won't kick in.
That is caused by the time between releasing swap and storing swapped
data inside the hard disk. If that is not gonna happen for a certain
amount of times, the OOM killer kicks. By reducing the throttling
interval, we simply pause more time over 256MB of memory, but an even
slower machine won't fit into these intervals of 64KB.

There's not a "clean" solution, but we can use the v2 cgroup support
for `memory.reclaim` and request enough data while we are swapping it.

On v1 we can either disable the cgroup OOM killer via memory.oom_control
so the child blocks instead of being killed, or keep the loop unthrottled
(the kernel already blocks faults in direct reclaim at memory.max) and
report an OOM kill as TBROK via the child's exit status.

Regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Wei Gao via ltp]

On Tue, Aug 25, 2026 at 12:16:08PM +0000, Andrea Cervesato wrote:
> Hi Wei,
> 
> > Reduce the throttling interval from 2 MB to 64 KB (usleep for 200us
> > every 64 KB) in the page-dirtying loop. This smooths out allocation
> > spikes and gives asynchronous swap writeback time to catch up under
> > slower VM storage environments, avoiding unexpected MemCG OOM-kills.
> 
> Unfortunately this is not a solution but a workaround, we need to make
> sure that we are able to see any change to the swap memory while
> allocating dirty pages close to the memory.max. This is probably a
> fix for a specific target rather than complete fix.
> 
> We need to find an another way to ensure that OOM killer won't kick in.
> That is caused by the time between releasing swap and storing swapped
> data inside the hard disk. If that is not gonna happen for a certain
> amount of times, the OOM killer kicks. By reducing the throttling
> interval, we simply pause more time over 256MB of memory, but an even
> slower machine won't fit into these intervals of 64KB.
> 
> There's not a "clean" solution, but we can use the v2 cgroup support
> for `memory.reclaim` and request enough data while we are swapping it.
The goal of this test is to reach memory.max and trigger kernel-driven 
swapping as a direct result of hitting that limit.
Proactively calling memory.reclaim forces swapping before reaching memory.max, 
meaning the memory limit is never actually reached. Furthermore, if calling memory.reclaim 
after hitting memory.max is too late to prevent OOM-kills on slow storage.
So i do not think `memory.reclaim` solution can help on our oom failure.

> 
> On v1 we can either disable the cgroup OOM killer via memory.oom_control
> so the child blocks instead of being killed, or keep the loop unthrottled
> (the kernel already blocks faults in direct reclaim at memory.max) and
> report an OOM kill as TBROK via the child's exit status.
> 
> Regards,
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Andrea Cervesato via ltp]

Hi Wei,

> The goal of this test is to reach memory.max and trigger kernel-driven 
> swapping as a direct result of hitting that limit.
> Proactively calling memory.reclaim forces swapping before reaching memory.max, 
> meaning the memory limit is never actually reached. Furthermore, if calling memory.reclaim 
> after hitting memory.max is too late to prevent OOM-kills on slow storage.
> So i do not think `memory.reclaim` solution can help on our oom failure.

memory.reclaim doesn't run during the pressure, but right after we
reached the memory limit, so OOM killer can be handled by excluding
it from the chain and getting an error instead of an OOM kill. In this
way we know if there's an error while swapping, instead of guessing that
device is too slow.

That's basically what we would do if we want to implement something
that is suitable for all the devices: we disable OOM killer in the cgroup,
we remove any sleep, we give a max runtime and if that is reached, it
means that after a number of attempts we are still not swapping -> TFAIL.

Just notice that what I just described is not so far from what OOM-killer
or memory.reclaim does. The ending result is exactly the same, but we
do things by hand.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Wei Gao via ltp]

On Wed, Aug 26, 2026 at 07:58:34AM +0000, Andrea Cervesato wrote:
> Hi Wei,
> 
> > The goal of this test is to reach memory.max and trigger kernel-driven 
> > swapping as a direct result of hitting that limit.
> > Proactively calling memory.reclaim forces swapping before reaching memory.max, 
> > meaning the memory limit is never actually reached. Furthermore, if calling memory.reclaim 
> > after hitting memory.max is too late to prevent OOM-kills on slow storage.
> > So i do not think `memory.reclaim` solution can help on our oom failure.
> 
> memory.reclaim doesn't run during the pressure, but right after we
> reached the memory limit, so OOM killer can be handled by excluding
> it from the chain and getting an error instead of an OOM kill. In this
> way we know if there's an error while swapping, instead of guessing that
> device is too slow.
> 
> That's basically what we would do if we want to implement something
> that is suitable for all the devices: we disable OOM killer in the cgroup,
> we remove any sleep, we give a max runtime and if that is reached, it
> means that after a number of attempts we are still not swapping -> TFAIL.
> 
> Just notice that what I just described is not so far from what OOM-killer
> or memory.reclaim does. The ending result is exactly the same, but we
> do things by hand.
> 
Thanks for the technical discussion, and we should find better solution
for avoid oom, but on cgroupv2(does not support disabling the OOM killer)
scenario, replacing sleep-based pacing with memory.reclaim is simply replacing 
one guess with another. In user-space, it is impossible to catch the exact 
second when memory hits memory.max. Furthermore, calling memory.reclaim proactively 
just guesses when to bypass memory.max altogether, which invalidates the 
core goal of the test.

> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Andrea Cervesato via ltp]

> Thanks for the technical discussion, and we should find better solution
> for avoid oom, but on cgroupv2(does not support disabling the OOM killer)
> scenario, replacing sleep-based pacing with memory.reclaim is simply replacing 
> one guess with another. In user-space, it is impossible to catch the exact 
> second when memory hits memory.max. Furthermore, calling memory.reclaim proactively 
> just guesses when to bypass memory.max altogether, which invalidates the 
> core goal of the test.

Less LLM please :-)

The OOM killer can be disabled in v2, but only for a specific group.

If you don't want to use memory.reclaim in v2 / disable OOM killer in v1,
then we need to do things by hand as explained in the previous comment,
for both v1 and v2.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Wei Gao via ltp]

On Wed, Aug 26, 2026 at 09:49:40AM +0000, Andrea Cervesato wrote:
> > Thanks for the technical discussion, and we should find better solution
> > for avoid oom, but on cgroupv2(does not support disabling the OOM killer)
> > scenario, replacing sleep-based pacing with memory.reclaim is simply replacing 
> > one guess with another. In user-space, it is impossible to catch the exact 
> > second when memory hits memory.max. Furthermore, calling memory.reclaim proactively 
> > just guesses when to bypass memory.max altogether, which invalidates the 
> > core goal of the test.
> 
> Less LLM please :-)
I just use AI polish my sentences; the idea is mine :)
> 
> The OOM killer can be disabled in v2, but only for a specific group.
The following document shows: cgroupv2 has memory.oom.group, but
is not used to disable the OOM killer.

Documentation/admin-guide/cgroup-v2.rst
  memory.oom.group
        A read-write single value file which exists on non-root
        cgroups.  The default value is "0".

        Determines whether the cgroup should be treated as
        an indivisible workload by the OOM killer. If set,
        all tasks belonging to the cgroup or to its descendants
        (if the memory cgroup is not a leaf cgroup) are killed
        together or not at all. This can be used to avoid
        partial kills to guarantee workload integrity.  <<<<<<<
> 
> If you don't want to use memory.reclaim in v2 / disable OOM killer in v1,
> then we need to do things by hand as explained in the previous comment,
> for both v1 and v2.

I guess "need to do things by hand" includes totally removing the hard
sleep time; currently, I have no good solution (as I mentioned in previous
comments, memory.reclaim is not an option).

But I don't object to disabling the OOM solution, as cgroup-v2.rst also
mentioned, we can protect task with oom_score_adj set to -1000,
this is maybe another option for fix our openqa failed case.
Do you think this is the preferred one?
> 
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Andrea Cervesato via ltp]

> I guess "need to do things by hand" includes totally removing the hard
> sleep time; currently, I have no good solution (as I mentioned in previous
> comments, memory.reclaim is not an option).

yes, basically we re-implement some sort of OOM-killer/memory.reclaim
inside the code, instead of using them directly. That means we need to
disable OOM killer, loop over the current swap status and eventually
raise an error if after N iterations pages are not swapped.

But I feel it's not deterministic because on a really slow device we
might run out of iterations. I still think memory.reclaim is the best
choice for v2 in this case, because it will wait until a certain amount
of memory has been reclaimed and eventually raise an error.

@Cyril do you have any idea on how to proceed here?	

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Cyril Hrubis]

Hi!
> yes, basically we re-implement some sort of OOM-killer/memory.reclaim
> inside the code, instead of using them directly. That means we need to
> disable OOM killer, loop over the current swap status and eventually
> raise an error if after N iterations pages are not swapped.
> 
> But I feel it's not deterministic because on a really slow device we
> might run out of iterations. I still think memory.reclaim is the best
> choice for v2 in this case, because it will wait until a certain amount
> of memory has been reclaimed and eventually raise an error.
> 
> @Cyril do you have any idea on how to proceed here?	

If the goal is to make sure that kernel swaps when memory.max is reached
we may as well slow down the dirtying loop so that it dirties memory
with speed 20MB/s when it gets close to the limit.

Something as:

diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
index 4e6023399..2c0c6fb02 100644
--- a/testcases/kernel/mem/mmapstress/mmapstress06.c
+++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
@@ -59,8 +59,9 @@ static void run_test(void)
 
                for (size_t i = 0; i < map_size; i += page_size) {
                        mmapaddr[i] = 'a';
-                       if ((i % (2 * 1024 * 1024)) == 0)
-                               usleep(1000);
+
+                       if (i >= mem_limit && !(i % (2 * 1024 * 1024)))
+                               usleep(100000);
                }

The testrun increses to 6s from 1s but it makes the OOM very unlikely to
happen.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Wei Gao via ltp]

On Thu, Aug 27, 2026 at 04:21:50PM +0200, Cyril Hrubis wrote:
> Hi!
> > yes, basically we re-implement some sort of OOM-killer/memory.reclaim
> > inside the code, instead of using them directly. That means we need to
> > disable OOM killer, loop over the current swap status and eventually
> > raise an error if after N iterations pages are not swapped.
> > 
> > But I feel it's not deterministic because on a really slow device we
> > might run out of iterations. I still think memory.reclaim is the best
> > choice for v2 in this case, because it will wait until a certain amount
> > of memory has been reclaimed and eventually raise an error.
> > 
> > @Cyril do you have any idea on how to proceed here?	
> 
> If the goal is to make sure that kernel swaps when memory.max is reached
> we may as well slow down the dirtying loop so that it dirties memory
> with speed 20MB/s when it gets close to the limit.
> 
> Something as:
> 
> diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
> index 4e6023399..2c0c6fb02 100644
> --- a/testcases/kernel/mem/mmapstress/mmapstress06.c
> +++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
> @@ -59,8 +59,9 @@ static void run_test(void)
>  
>                 for (size_t i = 0; i < map_size; i += page_size) {
>                         mmapaddr[i] = 'a';
> -                       if ((i % (2 * 1024 * 1024)) == 0)
> -                               usleep(1000);
> +
> +                       if (i >= mem_limit && !(i % (2 * 1024 * 1024)))
> +                               usleep(100000);
>                 }
> 
> The testrun increses to 6s from 1s but it makes the OOM very unlikely to
> happen.
Thanks for your suggestion.
I have tested above solution in our openqa setup but still encounter failure, 3 test cases
still failure with oom after run 100 cases. Maybe slow down dirty loop
is still too late?

> 
> -- 
> Cyril Hrubis
> chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Andrea Cervesato via ltp]

Hi Wei,

> > Something as:
> > 
> > diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
> > index 4e6023399..2c0c6fb02 100644
> > --- a/testcases/kernel/mem/mmapstress/mmapstress06.c
> > +++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
> > @@ -59,8 +59,9 @@ static void run_test(void)
> >  
> >                 for (size_t i = 0; i < map_size; i += page_size) {
> >                         mmapaddr[i] = 'a';
> > -                       if ((i % (2 * 1024 * 1024)) == 0)
> > -                               usleep(1000);
> > +
> > +                       if (i >= mem_limit && !(i % (2 * 1024 * 1024)))
> > +                               usleep(100000);
> >                 }
> > 
> > The testrun increses to 6s from 1s but it makes the OOM very unlikely to
> > happen.
> Thanks for your suggestion.
> I have tested above solution in our openqa setup but still encounter failure, 3 test cases
> still failure with oom after run 100 cases. Maybe slow down dirty loop
> is still too late?

I still believe there's no way to avoid this, unless we re-implement the
OOM-killer or memory.reclaim mechanism increasing the amount of attempts
per request. We will always encounter hardware that is too slow that
won't swap memory fast enough for the test.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Wei Gao via ltp]

On Tue, Sep 01, 2026 at 07:38:01AM +0000, Andrea Cervesato wrote:
> Hi Wei,
> 
> > > Something as:
> > > 
> > > diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
> > > index 4e6023399..2c0c6fb02 100644
> > > --- a/testcases/kernel/mem/mmapstress/mmapstress06.c
> > > +++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
> > > @@ -59,8 +59,9 @@ static void run_test(void)
> > >  
> > >                 for (size_t i = 0; i < map_size; i += page_size) {
> > >                         mmapaddr[i] = 'a';
> > > -                       if ((i % (2 * 1024 * 1024)) == 0)
> > > -                               usleep(1000);
> > > +
> > > +                       if (i >= mem_limit && !(i % (2 * 1024 * 1024)))
> > > +                               usleep(100000);
> > >                 }
> > > 
> > > The testrun increses to 6s from 1s but it makes the OOM very unlikely to
> > > happen.
> > Thanks for your suggestion.
> > I have tested above solution in our openqa setup but still encounter failure, 3 test cases
> > still failure with oom after run 100 cases. Maybe slow down dirty loop
> > is still too late?
> 
> I still believe there's no way to avoid this, unless we re-implement the
> OOM-killer or memory.reclaim mechanism increasing the amount of attempts
> per request. We will always encounter hardware that is too slow that
> won't swap memory fast enough for the test.

@Andrea @Cyril
As my former email suggestion "protect task with oom_score_adj set to -1000", and this can work
after 100 runs. If you agree this solution then i will create v2 new patch.


--- a/testcases/kernel/mem/mmapstress/mmapstress06.c
+++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
@@ -23,6 +23,7 @@
 #include <errno.h>
 #include <stdlib.h>
 #include "tst_test.h"
+#include "tst_memutils.h"

 static struct tst_cg_group *cg_child;
 static int page_size;
@@ -47,6 +48,8 @@ static void run_test(void)
                char *mmapaddr;
                unsigned long cg_swap_before = 0, cg_swap_after = 0;

+               tst_enable_oom_protection(0);
+
                /* Move child to the constrained cgroup */
                SAFE_CG_PRINTF(cg_child, "cgroup.procs", "%d", getpid());

@@ -57,11 +60,12 @@ static void run_test(void)

                tst_res(TINFO, "Dirtying %zu bytes in child", map_size);

-               for (size_t i = 0; i < map_size; i += page_size) {
+               /*
+                * Tasks with the OOM protection (oom_score_adj set to -1000)
+                * are treated as an exception and are never killed.
+                */
+               for (size_t i = 0; i < map_size; i += page_size)
                        mmapaddr[i] = 'a';
-                       if ((i % (2 * 1024 * 1024)) == 0)
-                               usleep(1000);
-               }

                SAFE_CG_SCANF(cg_child, "memory.swap.current", "%lu", &cg_swap_after);




> 
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Cyril Hrubis]

Hi!
> > diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
> > index 4e6023399..2c0c6fb02 100644
> > --- a/testcases/kernel/mem/mmapstress/mmapstress06.c
> > +++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
> > @@ -59,8 +59,9 @@ static void run_test(void)
> >  
> >                 for (size_t i = 0; i < map_size; i += page_size) {
> >                         mmapaddr[i] = 'a';
> > -                       if ((i % (2 * 1024 * 1024)) == 0)
> > -                               usleep(1000);
> > +
> > +                       if (i >= mem_limit && !(i % (2 * 1024 * 1024)))
> > +                               usleep(100000);
> >                 }
> > 
> > The testrun increses to 6s from 1s but it makes the OOM very unlikely to
> > happen.
> Thanks for your suggestion.
> I have tested above solution in our openqa setup but still encounter failure, 3 test cases
> still failure with oom after run 100 cases. Maybe slow down dirty loop
> is still too late?

AFAIK the swapping does not start until we are over the limit, so
slowing it down before we reach the limit is not going to change
anything. For v2 cgroup we can also set a soft limit memory.high to
slightly smaller number than memory.max, whith that the kernel would
start the swapping once memory.high was reached.

Something as:

if (!TST_CG_VER_IS_V1(cg_child, memory))
        SAFE_CG_PRINT(cg_child, "memory.high", "%lu", mem_limit - mem_limit/8);

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v2] mmapstress06: Use memory.high in cgroup v2 to start swapping early

[Wei Gao via ltp]

Set memory.high to slightly smaller than memory.max in cgroup v2 to
start swapping earlier. In cgroup v2, the asynchronous swap writeback
does not start until we are over the limit (memory.max). Setting
memory.high starts the reclaiming/swapping once memory.high is reached,
preventing the child process from hitting the memory.max limit and
getting killed by the OOM-killer.

Signed-off-by: Wei Gao <wegao@suse.com>
Suggested-by: Cyril Hrubis <chrubis@suse.cz>
---
v1->v2:
- Update solution base Cyril's suggestion

 lib/tst_cgroup.c                               | 1 +
 testcases/kernel/mem/mmapstress/mmapstress06.c | 7 +++++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/tst_cgroup.c b/lib/tst_cgroup.c
index 7c6ecd4d2..3ee9d32a4 100644
--- a/lib/tst_cgroup.c
+++ b/lib/tst_cgroup.c
@@ -180,6 +180,7 @@ static const struct cgroup_file memory_ctrl_files[] = {
 	{ "memory.events", NULL, CTRL_MEMORY },
 	{ "memory.low", NULL, CTRL_MEMORY },
 	{ "memory.min", NULL, CTRL_MEMORY },
+	{ "memory.high", "memory.soft_limit_in_bytes", CTRL_MEMORY },
 	{ "memory.max", "memory.limit_in_bytes", CTRL_MEMORY },
 	{ "memory.stat", "memory.stat", CTRL_MEMORY },
 	{ "memory.swappiness", "memory.swappiness", CTRL_MEMORY },
diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
index 4e6023399..7cc17fc75 100644
--- a/testcases/kernel/mem/mmapstress/mmapstress06.c
+++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
@@ -37,10 +37,13 @@ static void run_test(void)
 	/* Set memory limit to force swapping of the mapping */
 	SAFE_CG_PRINTF(cg_child, "memory.max", "%lu", (unsigned long)mem_limit);
 
-	if (TST_CG_VER_IS_V1(cg_child, "memory"))
+	if (TST_CG_VER_IS_V1(cg_child, "memory")) {
 		SAFE_CG_PRINT(cg_child, "memory.swap.max", "-1");
-	else
+	} else {
 		SAFE_CG_PRINT(cg_child, "memory.swap.max", "max");
+		SAFE_CG_PRINTF(cg_child, "memory.high", "%lu",
+			       (unsigned long)(mem_limit - mem_limit / 8));
+	}
 
 	child_pid = SAFE_FORK();
 	if (!child_pid) {
-- 
2.55.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] mmapstress06: Use memory.high in cgroup v2 to start swapping early

[linuxtestproject.agent]

Hi Wei,

On Wed, 2 Sep 2026, Wei Gao wrote:
> mmapstress06: Use memory.high in cgroup v2 to start swapping early

Verdict - Reviewed

---
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

Re: [LTP] [PATCH v2] mmapstress06: Use memory.high in cgroup v2 to start swapping early

[Andrea Cervesato via ltp]

Acked-by: Andrea Cervesato <andrea.cervesato@suse.com>

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v2] mmapstress06: Use memory.high in cgroup v2 to start swapping early

[Cyril Hrubis]

Hi!
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v2] mmapstress06: Use memory.high in cgroup v2 to start swapping early

[Andrea Cervesato via ltp]

Merged, Thanks!

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp