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

[Vlastimil Babka (SUSE)]

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?

> case, aren't we already in a desperately slow path? Does a little bit of
> extra work in __alloc_pages_direct_compact() really matter? I couldn't
> measure it in a benchmark (kernel compilation alongside stress-ng
> --secretmem).