On Wed, Dec 01, 2021, Ben Gardon wrote: > On Wed, Dec 1, 2021 at 11:22 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > I would prefer we use hugepage when possible, mostly because that's the terminology > > used by the kernel. KVM is comically inconsistent, but if we make an effort to use > > hugepage when adding new code, hopefully someday we'll have enough inertia to commit > > fully to hugepage. > > In my mind "huge page" implies 2M and "large page" is generic to 2m > and 1g. (IDK if we settled on a name for 1G pages) What about 4m PSE pages? :-) I'm mostly joking, but it does raise the point that trying to provide unique names for each size is a bit of a fools errand, especially on non-x86 architectures that support a broader variety of hugepage sizes. IMO, the least ambiguous way to refer to hugepages is to say that everything that isn't a 4k page (or whatever PAGE_SIZE is on the architecture) is a hugepage, and then explicitly state the size of the page if it matters. > I've definitely been guilty of reinforcing this inconsistent > terminology. (Though it was consistent in my head, of course.) If we > want to pick one and use it everywhere, I'm happy to get onboard with > a standard terminology. I hear you on using "large page", I've had to undo a solid decade of "large page" terminology from my pre-Linux days. But for better or worse, the kernel uses hugepage, e.g. hugetlbfs supports 1gb and 2mb pages. I think we should follow the kernel, especially since we have aspirations of unifying more of KVM's MMU across multiple architectures.
