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

[Li Zhe]

On 10/19/26 10:51 PM, Lorenzo Stoakes (ARM) wrote:
> On Mon, Oct 19, 2026 at 10:14:00PM +0800, Li Zhe wrote:
>> memory.reclaim was added as a generic proactive reclaim
>> interface for memcgs, but memory tiering makes its practical
> ...
>> The source= key is intentionally typed so future selectors can be
>> added without reinterpreting the nodes form. For example, later
>> patches may add source=tier:<selector> or other source types while
>> keeping source=nodes:<nodelist> as the NUMA-node source selector.
> Similar comment for the commit message as below re: simplicity.
>
>> Signed-off-by: Li Zhe <lizhe.67@xxxxxxxxxxxxx>
>> ---
>>   Documentation/admin-guide/cgroup-v2.rst | 23 ++++++++++++
>>   mm/internal.h                           |  3 +-
>>   mm/memcontrol-v1.c                      |  6 ++--
>>   mm/memcontrol.c                         | 11 +++---
>>   mm/vmscan.c                             | 48 +++++++++++++++++++++++--
>>   5 files changed, 81 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index 86a2a0099178..a016575010ba 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -1454,6 +1454,7 @@ The following nested keys are defined.
>>
>>   	  ==========            ================================
>>   	  swappiness            Swappiness value to reclaim with
>> +	  source                Source to apply reclaim pressure to
>>   	  ==========            ================================
>>
>>   	Specifying a swappiness value instructs the kernel to perform
>> @@ -1464,6 +1465,28 @@ The following nested keys are defined.
>>   	The valid range for swappiness is [0-200, max], setting
>>   	swappiness=max exclusively reclaims anonymous memory.
>>
>> +	The source key declares where the normal reclaim aging pipeline is
>> +	applied. It is a typed selector in the form source=<type>:<selector>.
>> +	Currently only source=nodes:<nodelist> is supported. For example::
>> +
>> +	  echo "1G source=nodes:0-1" > memory.reclaim
>> +
>> +	This instructs the kernel to apply reclaim pressure to memory of target
>> +	cgroup that are currently resident on nodes 0 and 1. Reclaim then
>> +	follows the normal reclaim path for selected folios. The source
>> +	selector does not choose a demotion or eviction policy. On tiered
>> +	memory systems, a source node in a non-terminal tier will usually make
>> +	progress through demotion when an allowed demotion target exists. A
>> +	source node in the terminal tier has no demotion target, so successful
>> +	reclaim progress from that source is eviction.
>> +
>> +	The source selector is a source constraint only. It does not select or
>> +	limit demotion targets; those are still chosen by the kernel's memory
>> +	tier demotion policy. Specifying source does not change reclaim
>> +	completion accounting. On tiered memory systems, completion may include
>> +	demotion progress that moves folios away from the selected source nodes
>> +	without reducing memory.current.
>> +
> I'm no cgroup expert so I can't really comment on the concept overall, but can I
> ask please that you try to make this documentation FAR simpler and clearer?
>
> I have no idea what an 'aging pipeline' is, then the paragraphs dive into
> significant detail and I don't see why you would want this or what it's useful
> for?
By "aging pipeline" I meant the combined reclaim behavior that may
demote some folios and evict others, depending on the existing reclaim
policy. But I agree that this wording is confusing here.
>
> You should lead with that, and keep things simple, only introducing detail
> later.
>
> Right now it's 'types:selector' (only 1 trivial example given) -> reclaim
> follows 'normal' path (what is 'normal'?) -> for selected folios (who selects
> them? How is it relevant to _an admin_?) -> source selector (what?) does NOT
> choose a demotion/eviction policy (neither defined in document) -> source node
> in non-terminal etc. etc.
>
> It's very typical of LLM-generated text - it treats the reader as a computer
> with a large mental 'stack' for storing this information.
>
> Humans don't work that way.
>
> The document targets _admins_ and this text strikes me as very very confusing
> for kernel developers, let alone admins.
>
> It also seems to assume a lot of knowledge.
Sorry for the confusion. I will rewrite the cgroup-v2.rst text in v2 to
be much clearer and easier to read.

Thanks,
Zhe
>
> --
> Cheers, Lorenzo