From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Jianlin Shi <shijianlin11@foxmail.com>, linux-mm@kvack.org
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH v2] mm/page_alloc: only update lowmem_reserve_ratio on sysctl write
Date: Fri, 31 Jul 2026 10:06:00 +0200 [thread overview]
Message-ID: <e0b27a56-2cba-4115-ad73-28e9387c040b@kernel.org> (raw)
In-Reply-To: <tencent_DB426A4AAD75DA751446F443770939B43205@qq.com>
Hm I also noticed you didn't cc everyone from PAGE ALLOCATOR section in
MAINTAINERS. Please use scripts/get_maintainers.pl next time.
On 7/31/26 05:42, Jianlin Shi wrote:
> lowmem_reserve_ratio_sysctl_handler() ignores the return value of
> proc_dointvec_minmax() and always calls setup_per_zone_lowmem_reserve(),
> even for read operations.
>
> Reading /proc/sys/vm/lowmem_reserve_ratio should not recompute per-zone
> lowmem_reserve[] and totalreserve_pages. Only do so when the sysctl is
> written, matching min_free_kbytes and watermark_scale_factor handlers.
>
> Also propagate errors from proc_dointvec_minmax() instead of ignoring
> them.
>
> Drop the manual "< 1 -> 0" sanitization loop in the handler and set
> .extra1 = SYSCTL_ZERO on the ctl_table entry so proc_dointvec_minmax()
> enforces the minimum on write (suggested by Vlastimil Babka).
It would be fair to explain the -EINVAL change in the compatibility note
too. FWIW I consider it low-risk.
> Compatibility note:
> Previously a read also sanitized sysctl_lowmem_reserve_ratio[] and
> called setup_per_zone_lowmem_reserve(), which rewrites each zone's
> lowmem_reserve[] and recalculates pgdat->totalreserve_pages /
> totalreserve_pages (visible via /proc/zoneinfo "protection" and used
> by page allocation fallback and dirty-limit accounting). After this
> change only a write does that. Documentation describes the meaning of
> the ratio and the derived protection pages, but does not document any
> read side-effect.
>
> Worst case for odd userspace that treated a read as a refresh of those
> derived values: lowmem_reserve[] and totalreserve_pages remain at their
> last written/setup values until the next write of this sysctl, or until
> another existing updater runs (e.g. adjust_managed_page_count() on
> managed-page changes, or init/watermark setup paths). Until then,
> allocation fallback into lower zones and per-node dirtyable memory
> (node_dirtyable_memory() subtracts pgdat->totalreserve_pages) may not
> reflect a refresh that such userspace expected from the read alone.
> Normal readers that only consume the ratio array are unaffected.
Well there should be no change to the totalreserve if nobody wrote new
ratios. Other paths that may change the result do call the update as you
describe. So this should have no observable effects anyway.
However, except watermark boosting hidden here in
calculate_totalreserve_pages():
/* we treat the high watermark as reserved pages. */
max += high_wmark_pages(zone);
The effect of boosting on this calculation was probably overlooked. I wonder
if we should also (as a separate patch) update it to use a value that
doesn't include boosting to make it stable and deterministic.
> Changes in v2:
> - Add .extra1 = SYSCTL_ZERO to the ctl_table entry
> - Remove the manual sanitization loop (negative writes now return
> -EINVAL instead of being silently coerced to 0)
Changes normally go under to the diffstat area* and are not part of commit
log. Hence the suggestion for the note for -EINVAL to be elsewhere.
>
> Link: https://lore.kernel.org/linux-mm/tencent_FFD4F4D728AAE8A8AE0AF277A59854A29A06@qq.com/
>
> Signed-off-by: Jianlin Shi <shijianlin11@foxmail.com>
> ---
*here
Otherwise LGTM.
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> mm/page_alloc.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0387d2afd..a7381327d 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6683,16 +6683,15 @@ static int sysctl_min_slab_ratio_sysctl_handler(const struct ctl_table *table, i
> static int lowmem_reserve_ratio_sysctl_handler(const struct ctl_table *table,
> int write, void *buffer, size_t *length, loff_t *ppos)
> {
> - int i;
> + int rc;
>
> - proc_dointvec_minmax(table, write, buffer, length, ppos);
> + rc = proc_dointvec_minmax(table, write, buffer, length, ppos);
> + if (rc)
> + return rc;
>
> - for (i = 0; i < MAX_NR_ZONES; i++) {
> - if (sysctl_lowmem_reserve_ratio[i] < 1)
> - sysctl_lowmem_reserve_ratio[i] = 0;
> - }
> + if (write)
> + setup_per_zone_lowmem_reserve();
>
> - setup_per_zone_lowmem_reserve();
> return 0;
> }
>
> @@ -6791,6 +6790,7 @@ static const struct ctl_table page_alloc_sysctl_table[] = {
> .maxlen = sizeof(sysctl_lowmem_reserve_ratio),
> .mode = 0644,
> .proc_handler = lowmem_reserve_ratio_sysctl_handler,
> + .extra1 = SYSCTL_ZERO,
> },
> #ifdef CONFIG_NUMA
> {
next prev parent reply other threads:[~2026-07-31 8:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 10:32 [PATCH] mm/page_alloc: only update lowmem_reserve_ratio on sysctl write Jianlin Shi
2026-07-30 15:28 ` Vlastimil Babka (SUSE)
2026-07-31 3:36 ` Jianlin Shi
2026-07-31 3:42 ` [PATCH v2] " Jianlin Shi
2026-07-31 8:06 ` Vlastimil Babka (SUSE) [this message]
2026-08-01 7:36 ` Johannes Weiner
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=e0b27a56-2cba-4115-ad73-28e9387c040b@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brendan.jackman@linux.dev \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shijianlin11@foxmail.com \
--cc=surenb@google.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