From: Michal Hocko <mhocko@suse.com>
To: Weilin Tong <tongweilin@linux.alibaba.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, vbabka@suse.cz,
surenb@google.com, jackmanb@google.com, hannes@cmpxchg.org,
ziy@nvidia.com, linux-kernel@vger.kernel.org,
baolin.wang@linux.alibaba.com
Subject: Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning
Date: Thu, 28 Aug 2025 08:45:44 +0200 [thread overview]
Message-ID: <aK_7GKJ4BWjye4tZ@tiehlicka> (raw)
In-Reply-To: <20250828030602.204332-1-tongweilin@linux.alibaba.com>
On Thu 28-08-25 11:06:02, Weilin Tong wrote:
> When min_free_kbytes is user-configured, increasing system memory via memory
> hotplug may trigger multiple recalculations of min_free_kbytes. This results
> in excessive warning messages flooding the kernel log if several memory blocks
> are added in a short period.
>
> Sample dmesg output before optimization:
> ...
> [ 1303.897214] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1303.960498] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1303.970116] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1303.979709] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1303.989254] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1303.999122] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1304.008644] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1304.018537] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1304.028054] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> [ 1304.037615] min_free_kbytes is not updated to 126529 because user defined value 1048576 is preferred
> ...
>
> Replace pr_warn() with pr_warn_once() to ensure only one warning is printed,
> preventing large volumes of repeated log entries and improving log readability.
pr_warn_once seems too aggressive as we could miss useful events. On the
other hand I agree that repeating the same message for each memory block
onlining is not really helpful. Would it make sense to only pr_warn when
new_min_free_kbytes differs from the previous one we have warned for?
>
> Signed-off-by: Weilin Tong <tongweilin@linux.alibaba.com>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index baead29b3e67..774723150e5b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6412,7 +6412,7 @@ void calculate_min_free_kbytes(void)
> if (new_min_free_kbytes > user_min_free_kbytes)
> min_free_kbytes = clamp(new_min_free_kbytes, 128, 262144);
> else
> - pr_warn("min_free_kbytes is not updated to %d because user defined value %d is preferred\n",
> + pr_warn_once("min_free_kbytes is not updated to %d because user defined value %d is preferred\n",
> new_min_free_kbytes, user_min_free_kbytes);
>
> }
> --
> 2.43.7
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2025-08-28 6:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-28 3:06 [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning Weilin Tong
2025-08-28 6:45 ` Michal Hocko [this message]
2025-08-28 9:23 ` Weilin Tong
2025-08-28 9:40 ` Michal Hocko
2025-08-28 9:48 ` Weilin Tong
2025-08-28 10:09 ` Michal Hocko
2025-08-28 10:30 ` Weilin Tong
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=aK_7GKJ4BWjye4tZ@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=surenb@google.com \
--cc=tongweilin@linux.alibaba.com \
--cc=vbabka@suse.cz \
--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.