Re: [RFC v2 1/1] mm: add source selector to memory.reclaim

[Li Zhe]

On Fri, 13 Nov 2026 02:20:20 -0500, gourry@xxxxxxxxxx wrote:

> > On 2026-11-02 15:04 +0800, Li Zhe wrote:
> > +	Specifying a source value constrains where proactive reclaim applies
> > +	pressure. Currently only source=nodes:<nodelist> is supported. For
> > +	example::
> > +
> > +	  echo "1G source=nodes:0-1" > memory.reclaim
> > +
> > +	This reclaims memory of the target cgroup resident on nodes 0-1.
> 
> you buried the fact that you want to allow source=zswap in your cover
> letter. I was confused by nodes: was needed here until i re-read.
> 
> As Joshua mentioned, i don't think you need the separate cover letter,
> and I agree this is far too long for the proposed change.

Agreed. The nodes: prefix was meant to keep source= a typed selector,
but I made the motivation and possible future extensions too long and
distracting. I will make v3 much clearer and shorter, and keep the focus
on source=nodes.

> ---
> 
> When I asked for testing, I wasn't concerned with the functionality,
> I was asking what problem this actually solves. performance? fairness?
> 
> Shaping the distribution of memory is neat and clearly works, but why
> does userspace want this?
> 
> The interface "lacking flexibility" is not a problem in and of itself.

Thanks, this is a fair point. Sorry, I also made that earlier
explanation too long, so let me summarize the intended use cases here:

https://lore.kernel.org/all/67fcd8db-269d-43f1-aea2-8c41165747d0@xxxxxxxxxxxxx/

In short, performance, fairness and cost are all part of the goal. One
target is mixed DRAM/CXL systems where user space keeps each memcg near
its own DRAM/CXL resident ratio target, based on the workload's
latency/throughput and cost requirements. Another target is the case you
described below, where user space wants memcg-scoped reclaim to apply
pressure to the desired tier first, rather than reclaiming from warmer
memory on the top tier. This is especially useful when a memcg is close
to its memory limit and user space wants charge-reducing reclaim to
start from colder/lower-tier memory first.

> I CAN see why you might want to proactively shape what data is swapped.
> Let me give you an example:
> 
> ---
> The global node reclaim interfaces allow us to put pressure on distinct
> nodes - which lets us shape which node is swapped from first.
> 
> Example: node0-1=DRAM, node2-3:CXL
> 
>   echo 1G > node2/reclaim   # swap from CXL
>   echo 1G > node3/reclaim   # swap from CXL
>   echo 1G > node0/reclaim   # demote to CXL
>   echo 1G > node1/reclaim   # demote to CXL
> 
> But the memcg.reclaim interface only allows us to pressure the complete
> set of cpuset.mems nodes for that memcg
> 
>   cat cpuset.mems           # 0-3
>   echo 1G > memory.reclaim  # makes progress from any of 0-3
> 
> Presently, proactive reclaim iterates nodes in node or fallback order,
> meaning it attempts to make progress from the fastest node possible
> first - which attempts to demote by default.  If the lower nodes are
> full, this demotion will fail and we'll swap directly from the top tier,
> which is (presumably) warmer than the bottom tiers.
> 
> Enable source-bound reclaim in the memory.reclaim interface so that user
> space can have the same control over memcg memory tiers that global
> proactive reclaim has.
> 
>   echo 2G source=nodes:2-3 > memory.reclaim  # [z]swap from CXL
>   echo 2G source=nodes:0-1 > memory.reclaim  # demote to CXL
> 
> This lets user proactive reclaim to target the coldest memory first
> rather than preferring to reclaim from node0 first and potentially
> swap out memory warmer than what is present on a CXL tier.
> ---
> 
> With this, you might be able to demonstrate fewer refaults and less
> DRAM (node0) memory consumed by zswap. These are clear benefits.

Thanks for the example. It makes the problem much easier to discuss. I
will refer to it when reworking the v3 motivation, and will avoid
framing the issue as a generic flexibility problem.

> I would argue that memory.reclaim should operate this way anyway,
> and that would could make proactive reclaim do this by default, but
> I could see the policy bits in userland being useful as well
> 
> Performance may not be the only reason you want this, but you need to
> help me understand what you're trying to accomplish.

Thanks again for the review and suggestions.

Thanks,
Zhe