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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

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.