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

["Brendan Jackman" <brendan.jackman@linux.dev>]

On Mon Jun 15, 2026 at 1:02 PM UTC, Vlastimil Babka (SUSE) wrote:
> On 6/11/26 16:46, Brendan Jackman wrote:
>> On Mon Jun 1, 2026 at 8:50 AM UTC, Vlastimil Babka (SUSE) wrote:
>>> On 5/29/26 17:02, Brendan Jackman wrote:
>>>> On Fri May 15, 2026 at 4:46 PM UTC, Brendan Jackman wrote:
>>>>> On Wed May 13, 2026 at 3:43 PM UTC, Vlastimil Babka (SUSE) wrote:
>>>> [...]
>>>>>> Uhh, speaking of compaction and reclaim... we rely on finding a whole free
>>>>>> pageblock in order to flip it. If that doesn't exist, the whole
>>>>>> get_page_from_freelist() will fail, and we might enter the
>>>>>> reclaim/compaction cycle in __allow_pages_slowpath(). But since we might
>>>>>> ultimately want an order-0 allocation, there won't be any compaction
>>>>>> attempted, because that code won't know we failed to flip a pageblock. And
>>>>>> the watermarks might look good and prevent reclaim as well I think? We
>>>>>> should somehow indicate this, and handle accordingly. Might not be trivial.
>>>>>> Or maybe reuse pageblock isolation code to do the migrations directly in
>>>>>> __rmqueue_direct_map?
>>>>>
>>>>> Ah, thanks, I suspect you are right.
>>>>>
>>>>> I did fear there would be some sort of case where this "not-quite
>>>>> reclaim" interacted badly with the actual reclaim, and I tried to test
>>>>> it by running some stuff in parallel with stress-ng (allocating
>>>>> __GFP_UNMAPPED via secretmem), and I didn't see a difference in the
>>>>> effective availability of memory. However, I suspect testing this is
>>>>> quite a deep art my "run these two commands that I copy pasted from an
>>>>> LLM suggestion" test was just crap.
>>>>>
>>>>> Do you have any workloads you can suggest for evaluating this kinda
>>>>> thing? We would definitely see it in Google prod (I think we see this
>>>>> kind of issue with our shrinker-based internal version of ASI distorting
>>>>> reclaim behaviour in ways even more subtle than this) but that is not a
>>>>> very practical experimental cycle...
>>>> 
>>>> I slop-coded a benchmark:
>>>> 
>>>> https://github.com/bjackman/kernel-benchmarks-nix/tree/master/packages/benchmarks/secretmem-vs-frag
>>>> 
>>>> It does some mmap/munmap patterns to try and generate fragmentation,
>>>> then spams secretmem allocations until it gets OOM-killed.
>>>> 
>>>> With this series, I see the OOM-kills happening noticeably sooner on a
>>>> 1GiB VM:
>>>> 
>>>> metric: secretmem_allocated_bytes (B)   |  test: secretmem-vs-frag
>>>> +---------------------------------------------+---------+-------------+-------------+-----------------+-------------+-------+
>>>> | kernel_release                              | samples |        mean |         min | histogram       |         max | Δμ    |
>>>> +---------------------------------------------+---------+-------------+-------------+-----------------+-------------+-------+
>>>> | 7.0.0-rc4-next-20260319                     |       4 | 683,147,264 | 643,825,664 |               █ | 715,128,832 |       |
>>>> | 7.0.0-rc4-next-20260319-00028-gf00246eb72cd |       3 | 623,553,195 | 551,550,976 |            ███  | 692,060,160 | -8.7% |
>>>> +---------------------------------------------+---------+-------------+-------------+-----------------+-------------+-------+
>>>> 
>>>> So... I think maybe I've reproduced the issue you pointed out? I will
>>>> try and fix it and see if this degradation goes away.
>>>
>>> Since I assume the fragmentating allocations are movable allocations, it
>>> might be the case, yeah.
>> 
>> Alright, so I tried splitting NR_FREE_PAGES_BLOCKS into two counters to
>> track mapped vs unmapped blocks. Then I gave
>> compaction_suit_allocation_order() an 'unmapped' flag:
>> 
>> 
>> @@ -2510,19 +2510,39 @@ bool compaction_zonelist_suitable(struct alloc_context *ac, int order,
>>  static enum compact_result
>>  compaction_suit_allocation_order(struct zone *zone, unsigned int order,
>>                                  int highest_zoneidx, unsigned int alloc_flags,
>> -                                bool async, bool kcompactd)
>> +                                bool unmapped, bool async, bool kcompactd)
>>  {
>>         unsigned long free_pages;
>>         unsigned long watermark;
>> 
>> -       if (kcompactd && defrag_mode)
>> +       /*
>> +        * Might need to generate a whole free block regardless of the actual
>> +        * allocation order:
>> +        *
>> +        * - When allocating an unmapped page, because the allocator only unmaps
>> +        *   whole blocks at a time.
>> +        *
>> +        *   Why doesn't this apply to the other way around too? (Mightn't we
>> +        *   need to _map_ a whole block?) This is a temporary simplification:
>> +        *   currently, unmapped blocks don't contain movable pages, so
>> +        *   compaction isn't going to free up one of those.
>> +        *
>> +        * - In defrag_mode, because the allocator is unwilling to "steal" pages
>> +        *   from the "wrong" block.
>> +        *
>> +        *   Why is this only under kcompactd?
>> +        *
>> +        * Temporary simplification: unmapped pageblocks are currently
>> +        * nonmovable. So if the compactor is trying to service a
>> +        */
>> +       if (unmapped)
>> +               free_pages = zone_page_state(zone, NR_FREE_PAGES_BLOCKS_MAPPED);
>> +       else if (kcompactd && defrag_mode)
>>                 free_pages = zone_free_pages_blocks(zone);
>>         else
>>                 free_pages = zone_page_state(zone, NR_FREE_PAGES);
>> 
>> 
>> ... Then, I changed __alloc_pages_direct_compact() to try to try to
>> compact for a whole block whenever we are trying to allocate an unmapped
>> page (note I think there's an orthogonal bug here where it leaks memory
>> when there's a "captured" compaction):
>> 
>> 
>> index 4f04e897c5374..7eed22f3b26eb 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -824,6 +824,9 @@ compaction_capture(struct capture_control *capc, struct page *page,
>>             capc_mt != MIGRATE_MOVABLE)
>>                 return false;
>> 
>> +       if (freetype_flags(freetype) != freetype_flags(capc->cc->freetype))
>> +               return false;
>> +
>>         if (migratetype != capc_mt)
>>                 trace_mm_page_alloc_extfrag(page, capc->cc->order, order,
>>                                             capc_mt, migratetype);
>> @@ -4469,20 +4472,27 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>>         struct page *page = NULL;
>>         unsigned long pflags;
>>         unsigned int noreclaim_flag;
>> +       unsigned int compact_order = order;
>> 
>> -       if (!order)
>> +       // TODO: Is it OK to always run compaction like this?
>> +       /*
>> +        * Unmapped allocations benefit from compaction even at order 0, because the
>> +        * allocator will actually grab a whole block.
>> +        */
>> +       if (freetype_flags(ac->freetype) & FREETYPE_UNMAPPED)
>> +               compact_order = pageblock_order;
>> +
>> +       if (!compact_order)
>>                 return NULL;
>> 
>>         psi_memstall_enter(&pflags);
>>         delayacct_compact_start();
>>         noreclaim_flag = memalloc_noreclaim_save();
>> 
>> -       *compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
>> -                                                               prio, &page);
>> +       // TODO: deal with captured page, if we changed the order it will have the
>> +       // wrong order. Also check it respects the freetype flags.
>> +       *compact_result = try_to_compact_pages(gfp_mask, compact_order,
>> +                                              alloc_flags, ac, prio, &page);
>> 
>>         memalloc_noreclaim_restore(noreclaim_flag);
>>         psi_memstall_leave(&pflags);
>> 
>> 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?