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

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

On 10/22/26 11:56 AM, Gregory Price (Meta) wrote:
> On 2026-10-20 21:01 +0800, Li Zhe wrote:
>> On 10/20/26 12:10 AM, Gregory Price wrote:
>>
>> 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.
>>
> The latter of these should probably be some level of the system default,
> that's why I brought it up as well.  (proactive reclaim should prefer to
> make progress from the coldest tier first, then work its way up).
>
> I'm not convinced a reclaim interface is the right way to affect a
> per-tier resident ratio policy.  That feels like a hack to get around
> solving the harder problem of something like tiered memcg counters
> (which would otherwise drive reclaim to work exactly the way you
> describe for resident ratios).


Thanks for the detailed comments.

I agree that improving the default proactive/async reclaim behavior can
be useful, and I also agree that tiered memcg counters/limits would be
useful. I do not see source=nodes as a replacement for those directions.
They solve different parts of the problem: tiered counters/limits provide
accounting and policy targets, while source=nodes is only an actuator for
proactive reclaim.

So I think these directions are compatible. A better default reclaim
policy or tiered memcg limits can improve kernel-driven behavior, while
source=nodes gives userspace an explicit way to apply reclaim pressure
to a selected resident source.

>
>> 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].
>>
> Yes and on its surface this is something I could see Meta using, however
> I question whether we're simply trying to find a convenient way around
> fixing reclaim to do the right thing (not invert the LRU, apply per-tier
> memcg limits, etc).


That is fair, and I do not intend this to avoid improving reclaim or
adding better tier-aware memcg accounting. A better memory.reclaim
algorithm would also make source=nodes more useful, because source=nodes
still uses the existing reclaim path after selecting the resident source.
The goal here is narrower: expose a source-scoped proactive reclaim
actuator while keeping the kernel's reclaim policy in control. The old
nodes= discussion had ABI problems, but it also showed that a
nodemask-like source selector is a useful primitive for finer-grained
proactive reclaim control [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.
>>
> Well, sort of, you get exposed to the implementation details by having
> to negotiate what is considered progress under different scenarios.
>
> Lets take one example - what should happen when:
>   - 2 node system, node0=DRAM, node1=CXL
>   - zswap is configured
>   - echo 1G source=nodelist:1 > memory.reclaim
>   - node 1 is pressured, zsmalloc falls back to node0 to allocate
>
> Should that be considered progress? We reclaimed from node1, but
> increased pressure on node0 - which might have kicked kswapd or memcg
> accounting to demote memory from node0 to node1.
>
> Should zswap also take that nodelist as a constraint?


This is a good example of why source=nodes should not be described as a
one-shot net footprint guarantee. Assuming source=nodes:1, the request
applies reclaim pressure to memcg memory resident on node1. That may
free some space on node1 in the short term, which can provide room for a
later node0-to-node1 demotion step. If zswap allocation, kswapd, or memcg
reclaim later moves pressure back across tiers and node1 usage rises
again, that is part of the dynamic reclaim/tiering behavior.

So userspace cannot rely on one write to memory.reclaim to produce a
final per-node distribution. The intended usage is a feedback loop: the
controller observes the memcg's resident distribution, chooses the source
nodes it wants to relieve, applies source-scoped reclaim pressure,
observes the new distribution, and iterates.

I do not think this patch should make source=nodes constrain zswap pool
allocations. That would be a different and much stronger semantic. The
current intent is only to constrain the resident source from which memcg
reclaim applies pressure, while completion accounting remains the
existing memory.reclaim accounting.

>
> At the very least i think you need to add details in your cover that
> demonstrates the process of doing something like per-node resident
> ratios, and show that it works as you intend.
Agreed. I will update the cover letter to make this model clearer. I
will also make clear that source=nodes is not a final net per-node
footprint guarantee and does not change memory.reclaim completion
accounting.

[1] https://lkml.org/lkml/2022/12/14/194

Thanks,
Zhe