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

[Usama Arif]

On 01/09/2026 20:01, 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>

Could this negatively affect x86 and arm64 systems using 4 KiB
pages?

This change reduces the free-memory headroom available for
compaction. That could reduce THP allocation success, especially
for GFP_TRANSHUGE_LIGHT allocations, which fail quickly rather
than performing direct reclaim or compaction.

With defrag=madvise, faults in MADV_HUGEPAGE regions may instead
incur additional synchronous reclaim or compaction latency.
khugepaged itself will not start later, but it may encounter more
fragmented memory and perform more work or fail more often.

I think it would be good to provide THP success, fallback, and
allocation-latency results under memory pressure for x86 and
arm64 4 KiB systems?