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

[Brendan Jackman]

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.