Re: [RFC 1/2] mm: add source selector to memory.reclaim
From: Lorenzo Stoakes (ARM)
Date: Mon Oct 19 2026 - 11:57:36 EST
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?
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.
--
Cheers, Lorenzo