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

[Lorenzo Stoakes (ARM)]

On Mon, Aug 31, 2026 at 09:47:29AM +0100, Kiryl Shutsemau wrote:
> On Mon, Aug 31, 2026 at 10:56:35AM +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.
> > 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 am not against an upper limit for min_free_kbytes, but I think the
> root cause of the problem you see is the size of the page block.
>
> We at Meta switched to 2M page blocks on 64k ARMs recently, targeting 2M
> mTHPs. A 512M pageblock is not practical.

I mean we do keep looping around on these things as 64 KiB page size is
fundamentally a big problem for the pageblock model :)

I don't love the idea of just making page blocks arbitrary smaller for
higher page table size, because hey the intent is to get a PMD-sized thing.

So really I think to do it 'properly' you'd need to rework how that whole
thing functions.

For me the approach here is a practical trade-off - if the intent is to cap
at a sensible value, then just cap at a sensible value.

>
> --
>   Kiryl Shutsemau / Kirill A. Shutemov

--
Cheers, Lorenzo