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
