On Thu, Apr 23, 2026 at 05:54:26PM +0200, David Hildenbrand (Arm) wrote: > On 4/23/26 16:46, Michael S. Tsirkin wrote: > > On Thu, Apr 23, 2026 at 04:13:50PM +0200, David Hildenbrand (Arm) wrote: > >> But really, that hugetlb code is rather messy. I'd vote for leaving hugetlb > >> alone on a v1, and focusing on non-hugetlb first. > > > > I just dislike it when things are non orthogonal. > > People are used to: hugetlb = same perf as THP but more predictable at the > > cost > > of being harder to use and using more resources. > > Here, suddenly, we have an optimization but only for THP. > > Note that we also didn't care about user_alloc_needs_zeroing() with hugetlb > so far.
You mean, that it stays because of the reserved pool? > It's not that it cannot be done with hugetlb, it's just a question about how > it > can be done more cleanly; and that requires more work to clean the hugetlb > part up. > > Best done separately. > > -- > Cheers, > > David
