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

[Weilin Tong <tongweilin@linux.alibaba.com>]

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