Re: [PATCH v5 00/18] mm: Some cleanups for page allocator APIs

From: Vlastimil Babka (SUSE)

Date: Fri Jul 10 2026 - 04:56:43 EST


On 7/10/26 10:36, Brendan Jackman wrote:
> On Sun, 5 Jul 2026 at 09:30, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> On Fri, 3 Jul 2026 14:47:32 +0200 "Vlastimil Babka (SUSE)" <vbabka@xxxxxxxxxx> wrote:
>>
>> > On 7/3/26 14:31, Brendan Jackman wrote:
>> > > Based on mm-new.
>> >
>> > Seems ready for mm-new to me. I suspect most further non-trivial page
>> > allocator work will conflict, so better have it in mm to be based upon.
>>
>> OK, thanks, added.
>>
>> I also added some little notes to track Zi Yan's comments.
>
> Thank Andrew. In this instance, what's the best way to send updates, I
> guess now they're in mm-new it's best to just send them as fixups for
> you to squash? In reply to the thread?
>
>> Sashiko had things to say, mainly pre-existing things.
>>
>> https://sashiko.dev/#/patchset/20260703-alloc-trylock-v5-0-c87b714e19d3@xxxxxxxxxx
>>
>> the xpc_create_gru_mq_uv() issues look like facepalms.
>
> Oh actually I didn't see the point about the alloc_pages_nolock()
> comment before. Other than that, yeah all of those comments have been
> discussed during the reviews, or are brokenness in totally unrelated
> code.
>
> There is this where we should probably make a decision (also a
> pre-existing issue but this time in mm/page_alloc.c):
>
> https://lore.kernel.org/all/DJOTMGFAPDBF.261U5OD4NPU74@xxxxxxxxx/

I think we can fix that in a follow-up patch. Tag it with Fixes: and stable
and see what happens. We shouldn't have to rearrange everything for small
fixes first just if it's just about !SMP.