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

[Yosry Ahmed]

On Tue, Aug 18, 2026 at 10:51 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> 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.

I think there's another lurking issue here. If we split a PUD mapping
to convert a pageblock, split_large_page() (on x86) will always use
GFP_KERNEL for the page table allocation. This is probably unsafe
(e.g. if the original allocation had GFP_NOIO or GFP_NOFS). We
probably want to use something like memalloc_apply_gfp_scope() here
anyway.