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

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

On 10/22/26 10:11 PM, Gregory Price wrote:
> On Thu, Oct 22, 2026 at 05:43:49PM +0800, Li Zhe wrote:
>> On 10/22/26 11:56 AM, Gregory Price (Meta) wrote:
>>
>> 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 think the critical question is what CAN userspace rely on?
>
> We can make a bunch of feedback loop interfaces, but there's no
> guarantee they'll actually be useful.

The reliable part I currently want to claim is narrow: userspace can ask
memory.reclaim to apply reclaim pressure to memcg memory resident on the
selected source nodes. It should not rely on a single write to produce a
final net per-node footprint. The existing memory.reclaim interface is
also a best-effort reclaim request rather than a deterministic placement
primitive; this patch only adds a way to select where that reclaim
pressure is applied.


>
>>> 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.
>>
> To be clear, I think not just making it clearer, but if you can show
> some tests that demonstrate the reliable behavior of the interface
> extension under different scenarios - that would be compelling.


That makes sense. I will run more detailed tests across different
scenarios and include the results in v2.

Thanks,
Zhe

>
> ~Gregory