+1 on this topic, thanks for bringing it up. This needs to be resolved, or it'll keep hanging over any future hugetlb feature changes. To me, it makes sense to have hugetlb pages themselves to just be large folios as much as possible. On top of that, there could be a notion of physical memory pools with certain properties. The properties can be things like: size, evictability, migratability, possibly persistence across reboots, maybe "should not be in the direct map", like memfd_secret. hugetlbfs then could be expressed as a filesystem on top of a pool of, for example, 1G non-evictable pages. The pools themselves could have a memfd-like interface (or use memfd itself), and could also be used to hook in to things like KVM guestmemfd. So yes, that would be a hugetlb v2, but mainly as a backward compatible layer on top of something more generic. - Frank On Thu, Feb 22, 2024 at 12:50 AM Peter Xu <peterx@xxxxxxxxxx> wrote: > > I want to propose a session to discuss how we should unify hugetlb into > core mm. > > Due to legacy reasons, hugetlb has plenty of its own code paths that are > plugged into core mm, causing itself even more special than shmem. While > it is a pretty decent and useful file system, efficient on supporting large > & statically allocated chunks of memory, it also added maintenance burden > due to having its own specific code paths spread all over the place. > > It went into a bit of a mess, and it is messed up enough to become a reason > to not accept new major features like what used to be proposed last year to > map hugetlb pages in smaller sizes [1]. > > We all seem to agree something needs to be done to hugetlb, but it seems > still not as clear on what exactly, then people forgot about it and move > on, until hit it again. The problem didn't yet go away itself even if > nobody asks. > > Is it worthwhile to spend time do such work? Do we really need a fresh new > hugetlb-v2 just to accept new features? What exactly need to be > generalized for hugetlb? Is huge_pte_offset() the culprit, or what else? > To what extent hugetlb is free to accept new features? > > The goal of such a session is trying to make it clearer on answering above > questions. > > [1] https://lore.kernel.org/r/20230306191944.GA15773@monkey > > Thanks, > > -- > Peter Xu > >
