Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB

[Lorenzo Stoakes (ARM)]

On Mon, Aug 31, 2026 at 11:00:13AM -0400, Zi Yan wrote:
> On 31 Aug 2026, at 5:34, Lorenzo Stoakes (ARM) wrote:
>
> > On Mon, Aug 31, 2026 at 11:20:30AM +0200, Michal Hocko wrote:
> >> On Mon 31-08-26 10:56:35, 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.
> >>> With MIGRATE_PCPTYPES equal to 3, the formula accounts for 11
> >>> pageblocks for every eligible populated zone before capping the result
> >>> at 5% of low memory.
> >>>
> >>> This is reasonable when a pageblock is 2 MiB, as on common 4 KiB page
> >>> configurations, but scales poorly with larger base page sizes. With
> >>> the default arm64 pageblock sizes, the contribution per eligible zone
> >>> before the 5% cap 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
> >>>
> >>> Consequently, min_free_kbytes can reach excessive and unwanted levels.
> >>>
> >>> Add an absolute 1 GiB cap to the recommendation, in addition to the
> >>> existing percentage cap. This bounds the automatic recommendation to a
> >>> sane value on systems with large pageblocks while preserving existing
> >>> behavior for typical systems with 2 MiB pageblocks.
> >>
> >> I would argue that the whole model of increasing min_free_kbytes for THP
> >> is wrong. This will trigger memory reclaim sooner and make the THP
> >> availability more likely but this was at times where we didn't have
> >> pro-active compaction and many changes in the compaction. So is this
> >> actually needed in general resp. only large pageblocks systems?
> >
> > Ohh even better :)
> >
> > I did find it strange that we increased accordingly.
> >
> > I'm more than happy to see this just die altogether if people agree that's
> > a sensible way forward...
>
> It sounds reasonable to me.
>
> My first reaction was that THP generation might be hurt due to fewer
> free pages. But probably the extra min_free_kbytes just moves reclaim earlier,
> like Michal said.
>
> After removing this automatic min_free_kbytes bump, user can retain the old
> behavior by setting a higher min_free_kbytes at boot time.

Nimrod - care to send a patch to just yank this min_free_kbytes change for
thp out? :)

This solves your problem another way and is neater overall.

>
> Best Regards,
> Yan, Zi

--
Cheers, Lorenzo