On Thu, Feb 22, 2024 at 3:50 AM Peter Xu <peterx@xxxxxxxxxx> wrote: > > I want to propose a session to discuss how we should unify hugetlb into > core mm. Or moving the interface part into a driver? > > 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 +1 I am interested in this discussion. Unification is indeed useful, and the core MM should ideally support only one kind of huge page. However, we must also ensure compatibility with the interfaces and features unique to hugetlb, such as boot-time reservation and vmemap optimizations. Generalizing these features could potentially lead to memory savings in THP as well. Pasha
