Re: [PATCH] mm: add memory.compact_unevictable_allowed cgroup attribute

[Michal Hocko <mhocko@suse.com>]

On Wed 18-03-26 13:08:31, Daniil Tatianin wrote:
> 
> On 3/18/26 1:01 PM, Michal Hocko wrote:
> > On Wed 18-03-26 12:25:17, Daniil Tatianin wrote:
> > > On 3/18/26 12:20 PM, Michal Hocko wrote:
> > [...]
> > > > Shouldn't those use mlock?
> > > Absolutely, mlock is required to mark a folio as unevictable. Note that
> > > unevictable folios are still
> > > perfectly eligible for compaction. This new property makes it so a cgroup
> > > can say whether its
> > > unevictable pages should be compacted (same as the global
> > > compact_unevictable_allowed sysctl).
> > If the mlock is already used then why do we need a per memcg control as
> > well? Do we have different classes of mlocked pages some with acceptable
> > compaction while others without?

OK, I have misread the intention and this is exactly focused at mlock
rather than general protection of all memcg charged memory. Now 

> The way it works is mlock(2) only prevents pages from being evicted
> from the page cache by setting unevictable | mlocked flags on the
> page. Such pages, however, are still allowed for compaction by
> default, unless /proc/sys/vm/compact_unevictable_allowed is set to 0.
> That property essentially "promotes" ALL such (unevictable) pages to a
> new synthetic tier by making compaction skip them. The per-cgroup
> property works similarly, however, it allows the scope to be much
> smaller: from a global setting that promotes literally ALL unevictable
> (mlocked) pages to this tier, to only promoting pages belonging to the
> cgroup that has memory.compact_unevictable_allowed as 0.

This is clear but what is not really clear to me is whether this is
worth having as mlock workloads are already quite specific, the amount
of mlocked memory shouldn't really consume huge portion of the memory so
you still need to have a solid usecase where such a micro management
really is worth it. In other words why a global
compact_unevictable_allowed is not sufficient.

-- 
Michal Hocko
SUSE Labs