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

On Tue Aug 18, 2026 at 2:55 AM CEST, Yosry Ahmed wrote:
...
>> [0]: https://lore.kernel.org/all/[email protected]/
>> 
>> > 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.

> 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...