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

[Johannes Weiner <hannes@cmpxchg.org>]

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.

> 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?

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.

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

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