Re: [PATCH v3] mm: remove min_free_kbytes adjustment for THP

[Johannes Weiner]

On Tue, Sep 01, 2026 at 10:01:23PM +0300, Nimrod Oren wrote:
> When THP is enabled, set_recommended_min_free_kbytes() may raise
> min_free_kbytes using a heuristic that scales with pageblock_nr_pages.
> Commit f000565adb77 ("thp: set recommended min free kbytes") added this
> heuristic to help keep pageblocks free and reduce fragmentation for THP
> allocations.
> 
> The recommendation scales poorly with larger base page sizes. With the
> default arm64 pageblock sizes, the contribution per eligible zone
> before applying the existing cap of 5% of low memory is:
> 
>   4 KiB pages:   2 MiB pageblock,   22 MiB per zone
>  16 KiB pages:  32 MiB pageblock,  352 MiB per zone
>  64 KiB pages: 512 MiB pageblock,  5.5 GiB per zone
> 
> Even with that cap, min_free_kbytes can reach excessive levels.
> 
> The automatic min_free_kbytes increase predates proactive compaction
> and many subsequent changes to compaction. Given those changes,
> increasing min_free_kbytes for THP by default is no longer clearly
> justified.
> 
> Remove set_recommended_min_free_kbytes() and all associated
> recalculation paths. With this policy gone, min_free_kbytes is
> controlled only by the page allocator's default calculation and the
> vm.min_free_kbytes sysctl. Users who want additional headroom may set a
> higher value via that sysctl.
> 
> Link: https://lore.kernel.org/r/20260831075635.2244437-1-noren@xxxxxxxxxx/
> Suggested-by: Michal Hocko <mhocko@xxxxxxxx>
> Signed-off-by: Nimrod Oren <noren@xxxxxxxxxx>

Just to summarize my take from the subthread with Zi: the premise of
this patch is to roll the regression dice on every THP setup out there
because certain ARM configurations result in a questionable pageblock size.

I'm not against carefully evaluating and testing out today's need for
set_recommended_min_free_kbytes() in real world examples. But this is
not that.

Nacked-by: Johannes Weiner <hannes@xxxxxxxxxxx>