Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
Subject: Re: [PATCH] mm/page_alloc: only update lowmem_reserve_ratio on sysctl write
Date: Thu, 30 Jul 2026 17:28:35 +0200	[thread overview]
Message-ID: <3105745c-f547-481c-a329-9b78ff4de0f8@kernel.org> (raw)
In-Reply-To: <tencent_FFD4F4D728AAE8A8AE0AF277A59854A29A06@qq.com>

On 7/28/26 12:32, Jianlin Shi wrote:
> lowmem_reserve_ratio_sysctl_handler() ignores the return value of
> proc_dointvec_minmax() and always sanitizes sysctl_lowmem_reserve_ratio
> and 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.
> 
> 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.
> 
> Signed-off-by: Jianlin Shi <shijianlin11@foxmail.com>
> ---
>  mm/page_alloc.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0387d2afd..ce33579ca 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6683,16 +6683,21 @@ 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 i, 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) {
> +		for (i = 0; i < MAX_NR_ZONES; i++) {
> +			if (sysctl_lowmem_reserve_ratio[i] < 1)
> +				sysctl_lowmem_reserve_ratio[i] = 0;
> +		}

Could we also get rid of this adjustment with proc_dointvec_minmax's
handling of tbl->extra1 set to SYSCTL_ZERO?

> +
> +		setup_per_zone_lowmem_reserve();
>  	}
>  
> -	setup_per_zone_lowmem_reserve();
>  	return 0;
>  }
>  



  reply	other threads:[~2026-07-30 15:28 UTC|newest]

Thread overview: 18+ 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) [this message]
2026-07-31  3:36   ` Jianlin Shi
2026-07-31  3:42 ` [PATCH v2] " Jianlin Shi
2026-07-31  8:06   ` Vlastimil Babka (SUSE)
2026-08-01  7:36   ` Johannes Weiner
2026-08-01 15:11 ` [PATCH v3] " Jianlin Shi
2026-08-01 18:44   ` Andrew Morton
2026-08-02 14:31     ` Jianlin Shi
2026-08-03  8:27     ` Vlastimil Babka (SUSE)
2026-08-04 12:20       ` Joel Granados
2026-08-04 14:33         ` Vlastimil Babka (SUSE)
2026-08-06  8:27         ` Joel Granados
2026-08-02 14:57 ` [PATCH v4] " Jianlin Shi
2026-08-04  0:48   ` Andrew Morton
2026-08-06  7:32     ` Jianlin Shi
2026-08-06  8:27 ` [PATCH v5] " Jianlin Shi
2026-08-06 13:50   ` 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=3105745c-f547-481c-a329-9b78ff4de0f8@kernel.org \
    --to=vbabka@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shijianlin11@foxmail.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