PageTransCompoundMap confusion

PageTransCompoundMap confusion

[Matthew Wilcox]

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().

Re: PageTransCompoundMap confusion

[Sean Christopherson]

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

Re: PageTransCompoundMap confusion

[Marc Zyngier]

On Fri, 04 Jun 2021 16:50:20 +0100,
Sean Christopherson <seanjc@google.com> 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.