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

[Gregory Price <gourry@gourry.net>]

On Wed, May 13, 2026 at 05:14:20PM +0000, Brendan Jackman wrote:
> On Wed May 13, 2026 at 4:17 PM UTC, Gregory Price wrote:
> >
> > Why not simply have an unmapped migratetype, for example, and on steal
> > you convert it to movable or whatever the preference is? 
> 
> Because the fact that only one migratetype currently supports being
> unmapped is a temporary happenstance of the guest_memfd usecase. In
> general, this needs to support having unmapped variants of ~arbitrary
> migratetypes.
>

Ah I see, that tracks.  Thank you for the context.

> >
> > Unless I'm fundamentally misunderstanding something, the pattern at least
> > seems similar.
> 
> Yeah, I actually only noticed that yesterday due to your posts on that
> thread! I need to investigate it further. My assumption has always been
> that this isn't a general solution because we don't always _have_ a user
> address (e.g. for guest_memfd it's important that we can populate the
> memory via write(), so there's no user address), but it's pretty likely
> I'm missing something there.
>

Hm.  I'm not quite wrapping my head around the TLB issue fully.

If there's no kernel direct mapping, and there's no userland mapping,
the stale TLB entry comes from... the page formerly being present in the
page tables and a stale TLB entry lying about after the page is freed?

If that's the case, that sounds more like someone isn't flushing the TLB
entry correctly when the page is freed or unmapped (for a transient
mermap situation), rather than an issue to be handled by the allocator.

I think I just need to spend a little more time understanding the TLB
issue.

> 
> The reason we need to do it at the block granularity is that a TLB flush
> every time we allocate one of these pages is a performance nonstarter -
> that's actually the entire point of this series. If you can afford a TLB
> flush per allocation then you don't need __GFP_UNMAPPED for the
> guest_memfd usecase, the existing direct map removal series [0] is
> already fine.
> 

That tracks.  So whatever the case, it seems like you prefer
block-granularity map/unmap operations, rather than per-allocation.

Do you have numbers on what the cost of map/unmap on a page vs block is?

Whatever the case is - you're pushing that cost onto *someone*, so
having that data would at least let us know the value of pushing most
memory to be unmapped by default rather than the opposite.

~Gregory