[PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[Weilin Tong]

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.

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

Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[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?

> 
> 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

Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[Weilin Tong]

在 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.

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.

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.
>> 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

Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[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.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[Weilin Tong]

[-- Attachment #1: Type: text/plain, Size: 3874 bytes --]


在 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?

[-- Attachment #2: Type: text/html, Size: 5587 bytes --]

Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[Michal Hocko]

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

Re: [PATCH RFC] mm: Use pr_warn_once() for min_free_kbytes warning

[Weilin Tong]

在 2025/8/28 18:09, Michal Hocko 写道:
> 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.
>
Understood, thank you for your suggestion.

I'm also looking forward to additional discussion and input from the 
community.