Re: [PATCH] mm/compaction: do not break pages whose order is larger than target order

["Zi Yan" <ziy@nvidia.com>]

On Thu Apr 24, 2025 at 3:42 PM EDT, Johannes Weiner wrote:
> On Thu, Apr 24, 2025 at 11:38:15PM +0800, Wenchao Hao wrote:
>> When scanning free pages for memory compaction, if the compaction target
>> order is explicitly specified, do not split pages in buddy whose order
>> are larger than compaction target order.

If such a free page exist, why is the compaction triggered? I assume
buddy allocator would use the free page for allocation.

I see your email to Baolin mentioning it is about proactive compaction.
In that scenario, the order is -1 and the added code does not apply,
right?

>
> Have you observed this to be an issue in practice?

I wonder the same.

The free pages are kept in cc.freepages list at its order.
compaction_alloc() tries to use a page with the smallest order from the
list to avoid split a large order free page. But if no small free pages
are available, compaction_alloc() will split a large free page to make
compaction going.

But what I do not understand is that if there is a free page with order
greater than cc->order, why didn't buddy allocator use it for
allocation?

>
> compact_finished() would have bailed if such a page had existed.
>
> compaction_capture() would steal such a page upon production.
>
> It could help with blocks freed by chance from somewhere else, where
> you'd preserve it to grab it later from the allocation retry. But if
> that's the target, it might be better to indeed isolate the page, and
> then capture it inside compaction_alloc()?

-- 
Best Regards,
Yan, Zi