Re: [PATCH] mm: stop recalculating min_free_kbytes once set by userspace

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 15 Oct 2026 19:16:40 +0300 Nimrod Oren <noren@nvidia.com> wrote:

> On 15/10/2026 0:48, Andrew Morton wrote:
> > On Wed, 14 Oct 2026 17:08:59 +0300 Nimrod Oren <noren@nvidia.com> wrote:
> > 
> >> min_free_kbytes is recalculated on memory hotplug and on THP sysfs
> >> writes. The new value comes from calculate_min_free_kbytes() or, while
> >> THP is enabled, from set_recommended_min_free_kbytes(). A value written
> >> to the vm.min_free_kbytes sysctl is replaced whenever the new value is
> >> higher, so a lower value does not stick. This matters most when THP is
> >> enabled on configurations with large pageblocks, where the new value
> >> can be excessive [1].
> >>
> >> Stop recalculating min_free_kbytes once a value has been written to the
> >> sysctl. Systems where the sysctl is never written keep the current
> >> behavior.
> > 
> > This problem lies somewhere in the range of "minor annoyance" to
> > "catastrophically horrible", but it isn't clear where in that range it
> > falls.
> > 
> > So can we please can we have a paragraph which explains the real-world
> > userspace-visible runtime effects of this problem?
> 
> Sure. Can we add the following after the first paragraph?
> 
>   For example, with default arm64 pageblock sizes, the THP
>   recommendation can reach 5.5 GiB per eligible zone with 64 KiB
>   pages vs 22 MiB with 4 KiB pages. This keeps a significant amount
>   of memory free, reducing what applications can use and triggering
>   reclaim much earlier. Users can lower vm.min_free_kbytes to avoid
>   this, but the lower value only sticks until the next recalculation.
> 

Thanks.

Do you (and others) feel that we should backport this?  Or is it just
not applicable to real-world users of older kernels?

If we expect there to be non-zero users of 64k-page kernels on older
versions then I think "yes, our users will benefit from this".