From: SeongJae Park <sj@kernel.org>
To: Joshua Hahn <joshua.hahnjy@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Matthew Brost <matthew.brost@intel.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel-team@meta.com
Subject: Re: [PATCH] mempolicy: Clarify what RECLAIM_ZONE means
Date: Fri, 25 Jul 2025 14:44:26 -0700 [thread overview]
Message-ID: <20250725214426.51487-1-sj@kernel.org> (raw)
In-Reply-To: <20250725173546.2295177-1-joshua.hahnjy@gmail.com>
Hi Joshua,
On Fri, 25 Jul 2025 10:35:45 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
> The zone_reclaim_mode API controls reclaim behavior when a node runs out of
> memory. Contrary to its user-facing name, it is internally referred to as
> "node_reclaim_mode". This is slightly confusing but there is not much we can
> do given that it has already been exposed to userspace (since at least 2.6).
>
> However, what we can do is to make sure the internal description of what the
> bits inside zone_reclaim_mode aligns with what it does in practice.
> Setting RECLAIM_ZONE does indeed run shrink_inactive_list, but a more holistic
> description would be to explain that zone reclaim modulates whether page
> allocation (and khugepaged collapsing) prefers reclaiming & attempting to
> allocate locally or should fall back to the next node in the zonelist.
>
> Change the description to clarify what zone reclaim entails.
>
> Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>
> ---
> include/uapi/linux/mempolicy.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/mempolicy.h b/include/uapi/linux/mempolicy.h
> index 1f9bb10d1a47..24083809d920 100644
> --- a/include/uapi/linux/mempolicy.h
> +++ b/include/uapi/linux/mempolicy.h
> @@ -69,7 +69,7 @@ enum {
> * These bit locations are exposed in the vm.zone_reclaim_mode sysctl
> * ABI. New bits are OK, but existing bits can never change.
> */
> -#define RECLAIM_ZONE (1<<0) /* Run shrink_inactive_list on the zone */
> +#define RECLAIM_ZONE (1<<0) /* Prefer reclaiming & allocating locally */
> #define RECLAIM_WRITE (1<<1) /* Writeout pages during reclaim */
> #define RECLAIM_UNMAP (1<<2) /* Unmap pages during reclaim */
I agree the new comment is more holistic. It explains general
zone_reclaim_mode behavior (how the system works if the mode is turned on by
having any of rightmost three bits is set) well. But, I think the old
description is for the specific mode of it (when the rightmost bit is set), and
the place is appropriate for that purpose.
What about keeping the old comment but adding the holistic description on the
upper multi-lines comments block?
And the behavior is also well described in zone_reclaim_mode section of
Documentation/admin-guide/sysctl/vm.rst document in my opinion. Maybe putting
a reference to the doc together for readers who curious about more details
could also be useful?
Thanks,
SJ
[...]
next prev parent reply other threads:[~2025-07-25 21:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 17:35 Joshua Hahn
2025-07-25 21:44 ` SeongJae Park [this message]
2025-07-26 1:24 ` Joshua Hahn
2025-07-28 1:44 ` Huang, Ying
2025-07-28 14:51 ` Joshua Hahn
2025-07-29 0:58 ` Huang, Ying
2025-07-30 20:19 ` Joshua Hahn
2025-07-31 1:48 ` Huang, Ying
2025-07-31 18:45 ` SeongJae Park
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=20250725214426.51487-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@redhat.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=rakie.kim@sk.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox