Re: PageTransCompoundMap confusion

[Sean Christopherson <seanjc@google.com>]

+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?