Re: [PATCH v2] mm/khugepaged: cap min_free_kbytes recommendation at 1 GiB
From: Lorenzo Stoakes (ARM)
Date: Mon Aug 31 2026 - 05:35:23 EST
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...
>
> --
> Michal Hocko
> SUSE Labs
--
Cheers, Lorenzo