From: Marc Zyngier <maz@kernel.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Yang Shi <yang.shi@linux.alibaba.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-mm@kvack.org, Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, Will Deacon <will@kernel.org>
Subject: Re: PageTransCompoundMap confusion
Date: Fri, 04 Jun 2021 17:18:54 +0100 [thread overview]
Message-ID: <87r1hhzjpt.wl-maz@kernel.org> (raw)
In-Reply-To: <YLpLvFPXrIp8nAK4@google.com>
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.
prev parent reply other threads:[~2021-06-04 16:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 14:49 PageTransCompoundMap confusion Matthew Wilcox
2021-06-04 15:50 ` Sean Christopherson
2021-06-04 16:18 ` Marc Zyngier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r1hhzjpt.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=aarcange@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yang.shi@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).