On Fri, Apr 24, 2026 at 08:30:40AM -0400, Gregory Price wrote: > 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
OK v4 incoming, thanks.
