Re: [PATCH v2 19/22] mm/page_alloc: implement __GFP_UNMAPPED allocations

[Vlastimil Babka (SUSE)]

On 6/15/26 15:08, Brendan Jackman wrote:
> On Mon Jun 15, 2026 at 1:02 PM UTC, Vlastimil Babka (SUSE) wrote:
>>> 
>>> Full code:
>>> https://github.com/bjackman/linux/tree/page_alloc-unmapped-2026-06-11
>>> 
>>> This makes the regression above (faster OOMs) go away, but it seems like
>>> a pretty blunt approach. But then I'm realising I don't really know why it
>>> matters?
>>
>> You mean, why does it matter that we don't OOM prematurely? I'd say that
>> matters a lot.
>>
>>> The main thing is presumably that we are more likely to
>>> pointlessly attempt compaction or compact more than we need. But in that
>>
>> I don't understand why that would be the case? If compaction thinks our goal
>> is order-0, there won't be any?
>>
>> Or you mean that it doesn't matter that your approach above is blunt, and
>> are talking about the consequences of that blunt approach?
> 
> Yeah exactly this - it seems to fix the issue, but I dunno if it's
> cheating. It _feels_ like cheating but I actually don't know what it
> would break - maybe nothing?

Ah ok, now I understand. Will have to check more closely if it can break
something. Maybe Johannes has some insight as he mentioned working on a
similar thing for the defrag mode?