On Fri, 04 Jun 2021 16:50:20 +0100,
Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> +Will and Marc
>
> On Fri, Jun 04, 2021, Matthew Wilcox wrote:
> > I'm a bit confused about what PageTransCompoundMap() is supposed to do.
> > What it actually does is check that the specific page (which may or
> > may not be a head page) is not mapped by a PTE. I don't understand why
> > you'd care how some (other?) process does or does not have it mapped.
> > What I _think_ you want to know is "Can I map this page with a PMD entry
> > in the guest". And the answer to that is simply:
> >
> > bool kvm_is_transparent_hugepage(kvm_pfn_t pfn)
> > {
> > struct page *head = compound_head(pfn_to_page(pfn));
> > return compound_order(head) >= HPAGE_PMD_ORDER;
> > }
> >
> > but maybe there's some reason you don't want to map hugetlbfs or other
> > sufficiently large compound pages with PMDs?
> >
> > Looking at the one caller of kvm_is_transparent_hugepage(), I'd be
> > tempted to inline the above into transparent_hugepage_adjust()
> > and call get_page() directly instead of indirecting through
> > kvm_get_pfn().
>
> arm64 is the only remaining user of kvm_is_transparent_hugepage().
>
> x86 purged its usage a while back, and instead looks at the host
> PTEs via lookup_address_in_mm() to get the current mapping level.
> The motivation was to consolidate the hugepage logic for THP,
> HugeTLBFS, and DAX, and to naturally support both 2mb and 1gb for
> all flavors of hugepages.
>
> Could arm64 do something similar and kill off
> kvm_is_transparent_hugepage() entirely?
Yup, we should be able to do that, although we get the additional fun
of caused by having 3 different page sizes. I'll have a go at it next
week.
Thanks for the heads up,
M.
--
Without deviation from the norm, progress is not possible.
