Re: [RFC 0/2] mm: add source selectors to memory.reclaim

["Li Zhe" <lizhe.67@bytedance.com>]

On 10/20/26 12:10 AM, Gregory Price wrote:
> On Mon, Oct 19, 2026 at 10:13:59PM +0800, Li Zhe wrote:
>> memory.reclaim is a useful proactive reclaim interface for memcgs, but
>> tiered memory makes "reclaim N bytes from this memcg" underspecified for
>> userspace controllers that manage memory placement across tiers. The
>> kernel's reclaim policy is aging-based, and on tiered systems aging may
>> demote folios before they are eventually evicted. Without a way to
>> declare where reclaim pressure should start, userspace can only reclaim
>> from the memcg as a whole and observe one aggregate progress value.
> This is not a good argument for pushing the complexity of managing tiers
> into userspace - it is an argument for fixing the reclaim interface to
> handle demotion and eviction sanely - which presently we do not do.
>
> My best examples:
>    1) the watermarks don't make sense for lower tiers that need to absorb
>       large amounts of demotions from upper tiers.  It's likely lower
>       tiers need larger WMARK_PROMO to let low-tier kswapd run longer.
>
>    2) proactive and async reclaim current reclaim top-down, which results
>       in swapping directly from top-tiers because lower tiers don't have
>       space to absorb demotions.  We should experiment with async /
>       proactive reclaim applying bottom-up (lowest tier first) so aging
>       the top-tiers demotes into lower tiers more successfully.
>
>       direct reclaim should stay top-down because we want the best page
>       with the least work to minimize stalls.
>
> I have a strong suspicion if we made these change, then memcg.reclaim
> would work more or less the way you'd want - and anything else can be
> managed more directly with madvise/process_madvise.
>
> I also have concerns with extending memory.reclaim this way permanently
> locking in reclaim implementation details that prevent us from making
> changes like this in the future.
>
> ~Gregory


Thanks for the feedback.

I agree that the kernel reclaim and demotion behavior still has room for
improvement, and the watermark changes and the bottom-up proactive/async
reclaim idea you mentioned may be useful to explore for some tiering
scenarios. But I think there is also an unavoidable userspace policy
component here. The kernel can improve whole-cgroup reclaim, but it
cannot know every controller's placement goal.

For example, one controller may want to keep a specific per-tier
resident ratio for a cgroup. Another use case, as Joshua pointed out in
another reply, is reclaiming from a lower tier first so that later
top-tier reclaim has room for demotion. A single default memory.reclaim
algorithm cannot express these per-cgroup policy choices.

I am not sure whether changing the default whole-cgroup reclaim behavior
in this direction could affect existing userspace dependencies. In the
old nodes= discussion, Mina mentioned that Meta's reclaim stack relied on
memory.reclaim triggering demotion [1].

I also do not intend source= to lock in current reclaim implementation
details. It should stay consistent with the current design: source= only
selects the resident source to which reclaim pressure is applied, while
the kernel remains free to change the reclaim policy.

The typed source= form also leaves room for future source selectors
without changing the meaning of source=nodes.

madvise and process_madvise are useful when userspace knows the target
virtual ranges or processes, but they are not a memcg-level interface
for applying reclaim pressure to a selected resident source.

So I tend to prefer the more conservative opt-in approach in this
patchset.

[1] https://lkml.org/lkml/2022/12/13/79

Thanks,
Zhe