On Wed, Dec 1, 2021 at 12:17 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > 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. Sounds good to me. I'll keep that in mind in future patches. I'm happy to call them anything as long as we all use the same terms.
