[LSF/MM/BPF TOPIC] Hugetlb Unifications

[Peter Xu <peterx@redhat.com>]

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