Re: [PATCH v3 21/26] mm/page_alloc: implement FREETYPE_UNMAPPED allocations

[Yosry Ahmed]

On Tue, Aug 18, 2026 at 4:04 AM Brendan Jackman
<brendan.jackman@xxxxxxxxx> wrote:
>
> On Tue Aug 18, 2026 at 2:55 AM CEST, Yosry Ahmed wrote:
> ...
> >> [0]: https://lore.kernel.org/all/20260805-shivank-gmem-migrate-v3-9-00d8bdec4e1d@xxxxxxx/
> >>
> >> > I wonder if we still need a fallback case where a pageblock contains a
> >> > mix of mapped and unmapped pages. We need to carefully handle such
> >> > pageblocks:
> >> > - For unmapped allocations, we need to unmap the relevant PTEs and
> >> >   potentially do a TLB shootdown (if they were previously mapped). Maybe
> >> >   we should always flush the TLB for simplicity for now.
> >> > - For mapped allocations, we need to map the relevant PTEs. No TLB
> >> >   shootdown should be needed.
> >> >
> >> > Assuming unmapped allocations are always zeroed by the users on alloc
> >> > and free, we don't need to worry about zeroing pages either way.
> >> >
> >> > We may want to track the number of unmapped pages in such page blocks to
> >> > now when it's fully mapped or fully unmapped and change its type, but
> >> > maybe this can be a followup if needed.
> >>
> >> ... However, yes this might be unavoidable despite what I said above.
> >> This was also DavidH's feeling when I chatted to him a few months back.
> >> The hard parts of it are a) the tracking as you hinted at and b) in the
> >> general case that means allocating pagetables.
> >
> > I am considering a simple-ish scheme to avoid per-page tracking and
> > potential TLB shootdowns in the freeing path (which prompted async
> > freeing internally).
> >
> > What if we just always map pages in such tainted/mixed pageblocks when
> > they are freed? If they are already mapped, nothing to do. If unmapped,
> > we map them and zero them. No TLB shootdown required.
> >
> > We also shouldn't ever need to allocate. If the pages were previously
> > unmapped, we should have already allocated any necessary page tables.
> > Right?
>
> Why would we already have allocated them?  In case it wasn't clear, I'm
> talking about breaking down huge mappings here.

If the pageblock is mixed, then the allocation path must have already
split huge mappings and allocated page tables as needed (or the
allocation would have failed). So the freeing path should be
guaranteed to not need to allocate.

Basically what I have in mind is, if you need to make an allocation
and you have to fallback to sharing a pageblock, you split the mapping
(if needed) and map/unmap memory. Now that might fail if you can't
allocate pages tables, or recurse into the allocator trying to share
another pageblock, etc. This can especially happen if you cannot find
a mapped pageblock to begin with.

So it's not very easy/straightforward. But at least all the complexity
should be in the allocation path where failures are tolerable to an
extent and the context is more-or-less known. The freeing path should
be straightforward-ish.

Technically you can still hit the same recursion case today if the
direct map was PUD-mapped, you will need to split the PUD to convert a
pageblock. But it's less likely to be a problem as the page table
allocation is mapped and if you have an intact PUD you probably have
tons of 4K mapped pages.

> > Zeroing on free may still be bad, but not prohibitive, and hopefully
> > this is only a fallback. We'll need to figure out where this fallback
> > fits (e.g. before or after reclaim/compaction).
>
> Yeah zeroing seems tolerable.
>
> >> So yeah I think it's probably doable but I _really_ want to avoid doing
> >> it in this series if we possibly can.
> >
> > Yeah I am trying to figure out whether the issue is theoretical enough
> > that we can do it in a follow up.
>
> I think it's definitely theoretical enough if secretmem is the only
> user. I hope given that guest_memfd usage is gated by a userspace opt-in
> that it's also automatically OK for that too...

Yeah unless we can come up with a very simple solution, I think we can
probably live with this for secretmem.