On Tue, Jan 7, 2025 at 4:39 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Mon 06-01-25 22:04:31, Yafang Shao wrote: > > On Mon, Jan 6, 2025 at 8:30 PM Michal Hocko <mhocko@xxxxxxxx> 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
