| Message ID | 20230218002819.1486479-17-jthoughton@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | hugetlb: introduce HugeTLB high-granularity mapping | expand |
On Fri, Feb 17, 2023 at 4:28 PM James Houghton <jthoughton@google.com> wrote: > > This is a simple change: don't create a "huge" PTE if we are making a > regular, PAGE_SIZE PTE. All architectures that want to implement HGM > likely need to be changed in a similar way if they implement their own > version of arch_make_huge_pte. > > Signed-off-by: James Houghton <jthoughton@google.com> > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > index 726d581158b1..b767b6889dea 100644 > --- a/include/linux/hugetlb.h > +++ b/include/linux/hugetlb.h > @@ -899,7 +899,7 @@ static inline void arch_clear_hugepage_flags(struct page *page) { } > static inline pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, > vm_flags_t flags) > { > - return pte_mkhuge(entry); > + return shift > PAGE_SHIFT ? pte_mkhuge(entry) : entry; > } > #endif > How are contig_pte's handled here? Will shift show that it's actually a contig_pte and not just PAGE_SHIFT? Or is that arm64 specific so it exists only in the arm64 version of this function? Do we need to worry about it here? > -- > 2.39.2.637.g21b0678d19-goog >
On Wed, Feb 22, 2023 at 1:18 PM Mina Almasry <almasrymina@google.com> wrote: > > On Fri, Feb 17, 2023 at 4:28 PM James Houghton <jthoughton@google.com> wrote: > > > > This is a simple change: don't create a "huge" PTE if we are making a > > regular, PAGE_SIZE PTE. All architectures that want to implement HGM > > likely need to be changed in a similar way if they implement their own > > version of arch_make_huge_pte. > > > > Signed-off-by: James Houghton <jthoughton@google.com> > > > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > > index 726d581158b1..b767b6889dea 100644 > > --- a/include/linux/hugetlb.h > > +++ b/include/linux/hugetlb.h > > @@ -899,7 +899,7 @@ static inline void arch_clear_hugepage_flags(struct page *page) { } > > static inline pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, > > vm_flags_t flags) > > { > > - return pte_mkhuge(entry); > > + return shift > PAGE_SHIFT ? pte_mkhuge(entry) : entry; > > } > > #endif > > > > How are contig_pte's handled here? Will shift show that it's actually > a contig_pte and not just PAGE_SHIFT? Or is that arm64 specific so it > exists only in the arm64 version of this function? Do we need to worry > about it here? arm64 implements its own version of arch_make_huge_pte, and 'shift' does indeed indicate (to arm64) if the PTE is contiguous or not (like it will be CONT_PTE_SHIFT, for example).
On 02/18/23 00:27, James Houghton wrote: > This is a simple change: don't create a "huge" PTE if we are making a > regular, PAGE_SIZE PTE. All architectures that want to implement HGM > likely need to be changed in a similar way if they implement their own > version of arch_make_huge_pte. > > Signed-off-by: James Houghton <jthoughton@google.com> > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > index 726d581158b1..b767b6889dea 100644 > --- a/include/linux/hugetlb.h > +++ b/include/linux/hugetlb.h Thanks, Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 726d581158b1..b767b6889dea 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -899,7 +899,7 @@ static inline void arch_clear_hugepage_flags(struct page *page) { } static inline pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags) { - return pte_mkhuge(entry); + return shift > PAGE_SHIFT ? pte_mkhuge(entry) : entry; } #endif
This is a simple change: don't create a "huge" PTE if we are making a regular, PAGE_SIZE PTE. All architectures that want to implement HGM likely need to be changed in a similar way if they implement their own version of arch_make_huge_pte. Signed-off-by: James Houghton <jthoughton@google.com>