Re: [LSF/MM/BPF TOPIC] A pagetable library for the kernel?

[Brendan Jackman <jackmanb@google.com>]

Slides: https://docs.google.com/presentation/d/1zcqEqRrpPR_K8LwcNIH8XpL7mk7mMcI_N1jJ67OWpYA/edit?slide=id.p#slide=id.p

Recap: We did not actually get onto the topic described in the proposal
at all! This was partly because while preparing for the session I began
to realise I don't think a grand vision is sensible here, instead I
think we just want to take incremental steps to share code in a small
number of reasonably obvious cases. Therefore, I allowed side
discussions to run on as long as they needed to, since I think they were
actually more interesting than the "real" topic.

I think these were the most important points of discussion:

1. This has a certain amount of similarity with Gregory Price's proposal
   [1] formerly known as "private memory". 

   I think the most important overlap was that both of our proposals
   involve adding GFP flags which is quite unpopular.

2. I proposed that in order to avoid __GFP_UNMAPPED, I would explore
   trying to make the unmapped allocation feature "private" to the page
   cache, giving it some sort of "side channel" to the allocator
   without exposing a dangerous API or consuming a GFP bit. 

   People didn't seem too offended by that idea so I do plan to pursue
   this, although it's still quite a vague proposition.

3. Although there are issues with the interfaces, the core page_alloc.c
   code is in a reviewable shape and I would LOVE to get some review of
   that. The relevant patch is here: [2]
   https://lore.kernel.org/all/20260320-page_alloc-unmapped-v2-19-28bf1bd54f41@google.com/
   (also the subsequent patch to add __GFP_ZERO support).

Also, from the hallway track: I am sorry that "mermap" looks like
"mremap"! I only noticed this after I had already sent proposals using
the new name. But, I'm not gonna propose a _third_ name for this thing
(I originally called it "ephmap" but this is extremely confusing when
vocalised), but I'm happy to return to the subject when all the
technical challenges are settled and we're talking about actually merging
commits.

[1] https://lore.kernel.org/all/af9i7dkNvGGxPHzu@gourry-fedora-PF4VCD3F/