Re: [RFC PATCH 3/5] mm/page_alloc: convert any movable pageblock on a non-movable allocation

[Dev Jain <dev.jain@arm.com>]

On 15/10/26 2:23 am, Rik van Riel wrote:
> On Wed, 2026-10-14 at 22:48 +0200, Johannes Weiner wrote:
>> On Tue, Oct 06, 2026 at 10:12:48PM -0400, Rik van Riel wrote:
>>> try_to_claim_block() converts a movable pageblock for a non-movable
>>> allocation only when half its pages are free or compatible.
>>> Otherwise the steal path takes pages without converting, and
>>> non-movable content sits in a block still typed movable.
>>>
>>> Convert a movable block on any non-movable claim, however few of
>>> its pages are free, so the block's type matches the allocation it
>>> serves.
>>>
>>> When other pages in the block are freed later, they end up on the
>>> non-movable free lists, directing more non-movable allocations to
>>> the already non-movable page blocks.
>>>
>>> Converting a non-movable pageblock to movable is made stricter:
>>> a movable claim takes a non-movable block only when every page
>>> is free or movable.
>>>
>>> Blocks straddling a zone edge are never claimed;
>>> zone_spans_pageblock() tests for a block wholly inside its zone.
>>>
>>> Assisted-by: LLM
>>> Signed-off-by: Rik van Riel <riel@surriel.com>
>>
>> I like this in theory, but wonder how this behaves in practice.
>>
>> The block is claimed, but the movable constituents aren't proactively
>> kicked out.
> 
> I have code for that, too, but it seems like
> it's a lot easier to get things reviewed in
> small portions.
> 
> If you want I can resend this as a larger
> series, with:
> 1) the pageblock claiming
> 2) per migrate type free lists
> 3) evacuation of movable pages from unmovable 
>    pageblocks, when the kernel free lists fall 
>    below a watermark
> 
> That would be the full extent of the 2MB granularity
> fragmentation avoidance stuff I have here.

I think your patch series applied as-is would regress stuff:
we may have lots of UNMOVABLE pageblocks with lots of
movable allocations, unable to be rescued, hurting mTHP
allocations.

> 
> Just let me know your preference.
>