All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Li Zhe <lizhe.67@bytedance.com>
Cc: akpm@linux-foundation.org, david@kernel.org, gourry@gourry.net,
	 ziy@nvidia.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com,
	 ying.huang@linux.alibaba.com, mhocko@suse.com,
	muchun.song@linux.dev, roman.gushchin@linux.dev,
	 shakeel.butt@linux.dev, weixugc@google.com,
	cgroups@vger.kernel.org,  linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC 1/2] mm: add source selector to memory.reclaim
Date: Mon, 19 Oct 2026 15:51:48 +0100	[thread overview]
Message-ID: <atYsvc9gIejcuwew@gremlin> (raw)
In-Reply-To: <20261019141401.11927-2-lizhe.67@bytedance.com>

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@bytedance.com>
> ---
>  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

  reply	other threads:[~2026-10-19 14:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 14:13 [RFC 0/2] mm: add source selectors to memory.reclaim Li Zhe
2026-10-19 14:14 ` [RFC 1/2] mm: add source selector " Li Zhe
2026-10-19 14:51   ` Lorenzo Stoakes (ARM) [this message]
2026-10-20  8:36     ` Li Zhe
2026-10-19 14:14 ` [RFC 2/2] mm: add tier " Li Zhe
2026-10-19 15:21 ` [RFC 0/2] mm: add source selectors " Joshua Hahn
2026-10-20  9:06   ` Li Zhe
2026-10-19 16:10 ` Gregory Price
2026-10-20 13:01   ` Li Zhe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=atYsvc9gIejcuwew@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizhe.67@bytedance.com \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=rakie.kim@sk.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=weixugc@google.com \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.