Re: [PATCH v2 00/22] mm: Add __GFP_UNMAPPED

[Gregory Price <gourry@gourry.net>]

On Fri, Mar 20, 2026 at 06:23:24PM +0000, Brendan Jackman wrote:
> 
> Because of these ambitious usecases, it's core to this proposal that the
> feature
> overloading the concept of a migratetype, this extension is done by
> adding a new concept on top of migratetype: the _freetype_. A freetype
> is basically just a migratetype plus some flags, and it replaces
> migratetypes wherever the latter is currently used as to index free
> pages.
>

I'm a bit confused why the need for additional level of indirection
instead of just adding a new migratetype.  You still end up increasing
the migratetype matrix, just with a new dimension.

(apologies if this was covered in prior work or discussions, just now
 plugging myself into the series).

Why not simply have an unmapped migratetype, for example, and on steal
you convert it to movable or whatever the preference is? 

> .:::: Hacky bits: simplistic secretmem integration
> 
> The secretmem integration leaves the mmain optimisations on the table;
> the security-required flushes of the mermap areas are implemented via
> distinct tlb_flush_mm() calls. It should be possible to amortize the
> mermap TLB flushes completely into the normal VMA flushing. However, as
> far as I know there is no performance-sensitive usecase for secretmem.
> So, I've just implemented the minimal adoption. This will at least avoid
> fragmentation of the direct map, even if it doesn't reduce TLB flushing.
> If anyone knows of a workload that might benefit from dropping that
> flushing, let me know!

Crossing a couple streams here, I wonder if there's some mechanisms
introduced by MST's latest multi-zeroing-avoidance [1] code that might
help deal with the problem here.

MST wired up an optional user_addr into the buddy that allows us to sink
the zeroing step for folio_zero_user (or folio_user_zero or whatever)
into the post_alloc_hook - which includes some cache flushing.

That conveniently gives you what you need for a TLB flush AND an
indicator that the allocation is intended for userland.

Unless I'm fundamentally misunderstanding something, the pattern at least
seems similar.

In that sense, does this just become a post_alloc_hook that unmaps the
memory after zeroing and allocation?

I get the intent is to have the majority of memory unmapped by default,
and then steal those blocks and map them as the kernel requires more
memory, but I wonder if it's cleaner to do it the other way and simply
have the buddy unmap on alloc after zeroing, and remap on free.

Seems like the free path would be trivial, check if the page is in the
direct map and if not, remap it and move on.  Entirely hidden from
existing users.

So, maybe a stupid question:  Was the opposite mechanism considered
(unmap on alloc sunk into the buddy), and if so was it rejected for some
other reason?

[1] https://lore.kernel.org/linux-mm/cover.1778616612.git.mst@redhat.com/

~Gregory