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

[Michal Hocko]

On Wed 02-09-26 12:23:23, Johannes Weiner wrote:
> 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.

I do hear your concerns Johannes. They are valid but I am not really
sure wht kind of testing would prove such a change to be safe.
 
> Nacked-by: Johannes Weiner <hannes@xxxxxxxxxxx>

-- 
Michal Hocko
SUSE Labs