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

[Michal Hocko]

On Tue 17-03-26 23:17:28, Daniil Tatianin wrote:
> 
> On 3/17/26 10:17 PM, Andrew Morton wrote:
> > On Tue, 17 Mar 2026 13:00:58 +0300 Daniil Tatianin <d-tatianin@xxxxxxxxxxxxxx> wrote:
> > 
> > > The current global sysctl compact_unevictable_allowed is too coarse.
> > > In environments with mixed workloads, we may want to protect specific
> > > important cgroups from compaction to ensure their stability and
> > > responsiveness, while allowing compaction for others.
> > > 
> > > This patch introduces a per-memcg compact_unevictable_allowed attribute.
> > > This allows granular control over whether unevictable pages in a specific
> > > cgroup can be compacted. The global sysctl still takes precedence if set
> > > to disallow compaction, but this new setting allows opting out specific
> > > cgroups.
> > > 
> > > This also adds a new ISOLATE_UNEVICTABLE_CHECK_MEMCG flag to
> > > isolate_migratepages_block to preserve the old behavior for the
> > > ISOLATE_UNEVICTABLE flag unconditionally used by
> > > isolage_migratepages_range.
> > AI review asked questions:
> > 	https://sashiko.dev/#/patchset/20260317100058.2316997-1-d-tatianin@xxxxxxxxxxxxxx
> 
> > Should this dynamically walk up the ancestor chain during evaluation to
> > ensure it returns false if any ancestor has disallowed compaction?
> 
> I think ultimately it's up to cgroup maintainers whether the code should do
> that, but as far as I understand the whole point of cgroups is that a child
> can override the settings of its parent. Moreover, this property doesn't
> have CFTYPE_NS_DELEGATABLE set, so a child cgroup cannot just toggle it at
> will.

In general any attributes should have proper hieararchical semantic. I
am not sure what that should be in this case. What is a desire in a
child cgroup can become fragmentation pressure to others.

I think it would be really important to explain more thoroughly about
those usecases of mixed workloads. Is the memcg even a suitable level of
abstraction for this tunable? Doesn't this belong to tasks if anything?
-- 
Michal Hocko
SUSE Labs