Message-ID: <aLAq5TaqdR7GQB6J@tiehlicka>
Date: Thu, 28 Aug 2025 12:09:41 +0200
From: Michal Hocko <mhocko@...e.com>
To: Weilin Tong <tongweilin@...ux.alibaba.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org, vbabka@...e.cz,
	surenb@...gle.com, jackmanb@...gle.com, hannes@...xchg.org,
	ziy@...dia.com, linux-kernel@...r.kernel.org,
	baolin.wang@...ux.alibaba.com
Subject: Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

On Thu 28-08-25 17:48:54, Weilin Tong wrote:
> 
> 在 2025/8/28 17:40, Michal Hocko 写道:
> > On Thu 28-08-25 17:23:40, Weilin Tong wrote:
> > > 在 2025/8/28 14:45, Michal Hocko 写道:
> > > 
> > > > 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?
> > > Thanks for your feedback!
> > > 
> > > The dmesg output above comes from hotplugging a large amount of memory into
> > > ZONE_MOVABLE, where new_min_free_kbytes does not actually change, resulting
> > > in repeated warnings with identical messages.
> > Yes, this is clear from the changelog
> > 
> > > However, if memory is hotplugged into ZONE_NORMAL (such as pmem-type
> > > memory), new_min_free_kbytes changes on each operation, so we still get a
> > > large number of warnings—even though the value is different each time.
> > We can check whether the value has changed considerably.
> > 
> > > If the concern is missing useful warnings, pr_warn_ratelimited() would be an
> > > acceptable alternative, as it can reduce log spam without completely
> > > suppressing potentially important messages. However I still think that
> > > printing the warning once is sufficient to alert the user about the
> > > overridden configuration, especially since this is not a particularly
> > > critical warning.
> > The thing is that kernel log buffer can easily overflow and you can lose
> > those messages over time, especially for system with a large uptime -
> > which is far from uncommon.
> > 
> > I am not entirely enthusiastic about rate limiting because that is time
> > rather than even driven. Anyway, if you can make ratelimiting work for
> > your usecase, then no objection from me but I would rather make the
> > reporting more useful than hack around it.
> 
> I agree with your suggestion.
> 
> With respect to your suggestion that “we can check whether the value has
> changed considerably” I would like to seek your advice on how to define what
> constitutes a significant change in this context. Do you have any
> recommended criteria or thresholds for determining when a difference in
> min_free_kbytes should trigger a warning?

No really. Certainly increasing min_free_kbytes by 1% would be barely
noticeable but 10% might show some difference. This will likely need to
be tuned on real life usecases so start with something and we can tune
that based on future usecases.

-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists