Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing

[Gregory Price]

On Fri, Apr 24, 2026 at 09:28:36AM +0200, David Hildenbrand (Arm) wrote:
> On 4/23/26 16:57, Gregory Price wrote:
> > On Thu, Apr 23, 2026 at 04:13:50PM +0200, David Hildenbrand (Arm) wrote:
> >> On 4/23/26 15:42, Gregory Price wrote:
> >>
> >> Maybe we could forward the vma+addr here and call a vma_alloc_froze_folio() if
> >> we have a VMA+addr to have a clean interface.
> >>
> >> But really, that hugetlb code is rather messy. I'd vote for leaving hugetlb
> >> alone on a v1, and focusing on non-hugetlb first.
> >>
> > 
> > If we're ok increasing the buddy surface this way, then I'd vote for
> > only updating the exact interfaces that MST needs to update for his use
> > case in a base set of patches, and then have each additional updated
> > location (or logical set of locations) updated in follow-ups.
> > 
> > My initial go around with this - the patch was hard to read at best.
> > 
> > But I also think we should also seriously consider not increasing the
> > surface of the buddy. 
> 
> Exactly, that's why I am saying that vma_alloc_folio() is the only external
> interface people should be using with a user address. all other _noprof helpers
> are supposed to be internal.
> 
> For hugetlb, we might need another interface for frozen folios later, which is
> why I suggest to defer that.
> 

Yeah I follow now - we're of the same mind on all this then.

~Gregory