Re: [PATCH] mm: add memory.compact_unevictable_allowed cgroup attribute
From: Daniil Tatianin
Date: Wed Mar 18 2026 - 10:05:04 EST
On 3/18/26 2:47 PM, Michal Hocko wrote:
On Wed 18-03-26 13:08:31, Daniil Tatianin wrote:
On 3/18/26 1:01 PM, Michal Hocko wrote:OK, I have misread the intention and this is exactly focused at mlock
On Wed 18-03-26 12:25:17, Daniil Tatianin wrote:
On 3/18/26 12:20 PM, Michal Hocko wrote:[...]
If the mlock is already used then why do we need a per memcg control asShouldn'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).
well? Do we have different classes of mlocked pages some with acceptable
compaction while others without?
rather than general protection of all memcg charged memory. Now
The way it works is mlock(2) only prevents pages from being evictedThis is clear but what is not really clear to me is whether this is
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.
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.
In my opinion both mlocked memory and non-compactible memory have the right to
co-exist on the same host without a global switch that turns one into the other. I agree
that it's not a super common thing, but I still think it can be beneficial.
Some examples include but not limited to: security: so that sensitive data is never swapped
to disk yet we have no problem if it gets compacted and the actual physical page gets replaced,
performance for some apps: so that we can e.g. memlock a large binary in memory to keep it in
page cache and improve startup time, but again don't care much if the actual backing pages are
replaced via compaction.
On the other hand, some critically important/real time applications do need protection from compaction
as well on top of the regular mlock, so that they have predictable latency and response time, which can
really fluctuate during heavy compaction. Both of these cases can coexist on the same physical machine.