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

[Lorenzo Stoakes (ARM)]

On Fri, Sep 04, 2026 at 11:43:46AM -0400, Johannes Weiner wrote:
> On Thu, Sep 03, 2026 at 04:46:18PM +0100, Lorenzo Stoakes (ARM) wrote:
> > Looking over the sub-thread (correct me if I'm wrong) the issues seem to be:
> >
> > - 512 MB pageblocks become unmoveable quicker than expected
> >
> > - When trying to convert a pageblock in try_to_claim_block() 256 MiB is required
> >   to be of the desired migratetype, and this is difficult to achieve vs. 1 MiB
> >   (yes clearly :)
> >
> > - AI training checkpointing was a problematic workload - big latency spikes and
> >   timeouts. Tonnes of unmoveable memory, order-0 allocations falling back to
> >   MIGRATE_MOVABLE (ugh), exhibiting try_to_claim_block() symptoms above.
> >
> > I hear all of this, and to be clear - this kind of real-world data, at scale, is
> > the kind of thing we should base decisions on more than anything else.
> >
> > Reality > theory every time (and the more you look into the kernel you more you
> > realise it's a tower of heuristics anyway, especially in classical reclaim :)
> >
> > I guess what you're trying to say here is the only way in these circumstances to
> > make headway would be to have more memory reserved.
> >
> > But is that the right conclusion? Aren't you still screwed once those reserves
> > are chomped up?
> >
> > Or are you saying the increased watermark levels gets you effective
> > kcompactd/kswapd sooner?
>
> +1 Exactly! The watermarks sit on top of that reserve. Both background
> reclaim and direct reclaim are thresholded such that there are always
> a few pageblocks worth of free space for the allocator to choose from,
> thus reducing the risk of fallbacks and block poisoning.

Right.

>
> > The TL;DR for me is - you have a workload that's broken already with larger
> > pageblock size - maybe you could test that with/without this patch and see if it
> > really does help?
> >
> > Anyway it seems to me all of this is essentially a (valid!) critique of
> > assumptions backed into the page allocator code.
>
> This part I don't quite follow. Why is the page allocator doing
> anything wrong here?

In this bit of the email we were talking about a function that lives in
page_alloc.c :)

>
> You tell it your largest routine allocation size. It groups smaller
> allocations by their ability to move into buckets of this size,
> coordinates a headroom of buckets for non-violating placements, and
> ensures reclaim kicks in when that headroom depletes.

Yup, but as discussed if something straddles the buckets it's useless (it can
only make guarantees about the buckets themselves), the target everything has in
mind is PMD (since we are bumping the reserves for THP explicitly), and
alignment/size requirements make smaller sizing useless for mTHP.

>
> You're giving it a very large bucket size and are not happy with the
> headroom that commands.

Yup.

>
> [ I'll reply to the other points in your email later. ]

--
Cheers, Lorenzo