Re: [PATCH 1/2] mm: page_alloc: do not give all non-blocking requests reserve access
From: Vlastimil Babka (SUSE)
Date: Thu Oct 29 2026 - 06:06:18 EST
On 10/29/26 06:55, Andrew Morton wrote:
> On Wed, 28 Oct 2026 15:41:48 +0100 Christoph Hellwig <hch@xxxxxx> wrote:
>
>> On Tue, Oct 27, 2026 at 03:00:02PM +0000, Salvatore Dipietro wrote:
>> >
>> > Hi Johannes,
>> >
>> > Vlastimil asked that v6 of my page_alloc patch [1] not go to mainline
>> > before these two patches land, so Andrew parked v6 at the tail of
>> > mm-unstable and dropped its Cc: stable until then.
>> >
>> > Are you still planning to work on 1/2 and 2/2, and if so, do you have
>> > a rough ETA? Or would you rather post them as a separate series as
>> > they are? If anything is needed on my side to move them forward, I'm
>> > happy to help.
>> >
>> > For what it's worth, I ran both stacked under v6 on v7.3-rc1 and saw
>> > no performance difference on my benchmark with or without them.
>>
>> It would be really important to get some fix for this into 7.3.
>> We can still perfect it later.
>
> What is "this"? You're referring to the performance regression which
> Salvatore's "mm/page_alloc: avoid direct reclaim and compaction for
> costly __GFP_NORETRY allocations" addresses?
>
> In
> https://lore.kernel.org/all/9f415dc7-adad-4161-b20d-7c3173f50ff3@xxxxxxxxxx/
> vbabka indicated that Fixes: 281dd25c1a01 is needed on that patch. The
"that patch" being Johannes's and the v2 you picked up has it
> patch I'm sitting on (below) has Fixes: 5d8edfb900d5. Please clarify.
It's correct.
> In
> https://lore.kernel.org/all/c6e2c1e1-a285-406e-a2b6-c09e05df91d8@xxxxxxxxxx/
> vbabka argued that Salvatore's "mm/page_alloc: avoid direct reclaim and
> compaction for costly __GFP_NORETRY allocations" should be a 7.4 thing.
>
> So it's all clear as mud. Can people please clarify?
>
> I have hannes's series "mm: page_alloc: fix reserve access for
> non-blocking requests, v2" in mm-hotfixes, planned for 7.4-rcX.
>
> Should I move Salvatore's "mm/page_alloc: avoid direct reclaim and
> compaction for costly __GFP_NORETRY allocations, v6" into mm-hotfixes
> also, and restore its cc:stable?
>
> My vote: "yes" - that's a pretty obnoxious perf regression.
Yes please.