linux-kernel - Re: [PATCH RFC] mm: Use pr_warn_once() for min_free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <35e0a580-ae78-4485-b285-7f71f91e046d@linux.alibaba.com>
Date: Thu, 28 Aug 2025 17:23:40 +0800
From: Weilin Tong <tongweilin@...ux.alibaba.com>
To: Michal Hocko <mhocko@...e.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

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