Re: [PATCH RFC 00/19] mm: Add __GFP_UNMAPPED

[Brendan Jackman <jackmanb@google.com>]

Hi Rick, sorry I was just scanning over this thread again while prepping
the next version and noticed I never replied to this.

On Fri Mar 6, 2026 at 5:38 PM UTC, Rick P Edgecombe wrote:
> On Wed, 2026-02-25 at 16:34 +0000, Brendan Jackman wrote:
>> __GFP_UNMAPPED
>
> Haven't looked at this in detail, but there was some previous work that even
> used the same flag name. In the end, the discussion leaned towards a dedicated
> API instead of a flag. Not saying the flag approach is dead, but might useful to
> explain how it fits in with that discussion.
>
> https://lore.kernel.org/lkml/20230308094106.227365-1-rppt@kernel.org/

I am not at all wed to using a GFP flag for this, but a key difference
between this and Mike's original __GFP_UNMAPPED is that this is
integrated directly into the page allocator itself, and that's a
load bearing element. 

Technically speaking, in this series __GFP_UNMAPPED is only supported
for unmovable allocations, but that's just to avoid bloating the data
structures (there isn't a user for that type of allocation yet, so
there's no point in creating freelists for it). But, in principle, the
goal here is to support all the fancy stuff that the mm does for this
memory. That's important because for the real usecases I have in mind
here, the vast majority of memory in the system should eventually be
relying on the page allocator to unmap it (either completely as in
__GFP_UNMAPPED, or just from the special ASI pagetables as in
__GFP_SENSITIVE, which will be added later).

So, yeah we can always have a special API but that would be a bit of a
roundabout way to just save a bit in a an enum, it wouldn't actually
represent any simplification of the page allocator's API.

Anyway thanks for pointing this out, I will neded to explain this in the
next version's cover letter, but in the meantime there's a quick
braindump of my thinking.