Re: [RFC PATCH 0/2] memcg: add nomlock to avoid folios beling mlocked in a memcg

[Yafang Shao <laoar.shao@gmail.com>]

On Tue, Jan 7, 2025 at 4:39 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Mon 06-01-25 22:04:31, Yafang Shao wrote:
> > On Mon, Jan 6, 2025 at 8:30 PM Michal Hocko <mhocko@suse.com> wrote:
> > >
> > > On Wed 25-12-24 10:23:53, Yafang Shao wrote:
> > > [...]
> > > > - Option C: Reparent the mlocked page to a common ancestor
> > > >
> > > > Consider the following hierarchical:
> > > >
> > > >          A
> > > >     /        \
> > > >   B           C
> > > >
> > > > If B is mlocking a page in C, we can reparent that mlocked page to A,
> > > > essentially making A the new parent for the mlocked page.
> > >
> > > How does this solve the underlying problem?
> >
> > No OOM will occur in C until the limit of A is reached, and an OOM at
> > that point is the expected behavior.
>
> Right but if A happens to be the root cgroup then you effectivelly
> allows mlock to run away a local limit.

Typically, in a real production environment, people don't use mlock on
large amounts of file cache. It’s unusual for one instance to lock a
significant amount of file cache and share it with another instance.
If such use cases do exist, it would be more appropriate to use
memory.min rather than relying on mlock().

For most users, allowing mlocked file pages to be unrestricted is
acceptable. I don’t think we should worry too much about edge cases in
this regard. However, if it is deemed a concern, we could introduce a
"cgroup.memory=mlock_shared" boot parameter to enable this behavior
explicitly.


--
Regards
Yafang