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

[Wei Gao]

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