| Message ID | 20220903123640.719846-1-mpe@ellerman.id.au (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] powerpc/mm/64s: Drop pgd_huge() | expand |
Le 03/09/2022 à 14:36, Michael Ellerman a écrit : ... > > However in commit ba95b5d03596 ("powerpc/mm/book3s/64: Rework page table > geometry for lower memory usage") the page table layout was reworked to > shrink the size of the PGD. > > As a result the 16GB page size now fits at the PUD level when using 64K > base page size. > > Therefore there are no longer any supported configurations where > pgd_huge() can be true, so drop the definitions for pgd_huge(), and > fallback to the generic definition which is always false. We also have pgd_huge defined as always false in: arch/powerpc/include/asm/page.h arch/powerpc/include/asm/nohash/pgtable.h Those could be removed as well as there is a default definition in include/linux/hugetlb.h And then all uses of pgd_huge() in the core mm can be dropped because powerpc was the only user. Christophe
Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Le 03/09/2022 à 14:36, Michael Ellerman a écrit : > > ... > >> >> However in commit ba95b5d03596 ("powerpc/mm/book3s/64: Rework page table >> geometry for lower memory usage") the page table layout was reworked to >> shrink the size of the PGD. >> >> As a result the 16GB page size now fits at the PUD level when using 64K >> base page size. >> >> Therefore there are no longer any supported configurations where >> pgd_huge() can be true, so drop the definitions for pgd_huge(), and >> fallback to the generic definition which is always false. > > We also have pgd_huge defined as always false in: > arch/powerpc/include/asm/page.h > arch/powerpc/include/asm/nohash/pgtable.h > > Those could be removed as well as there is a default definition in > include/linux/hugetlb.h Yep. > And then all uses of pgd_huge() in the core mm can be dropped because > powerpc was the only user. The original reason I looked at this is because Mike was looking at things on the mm side and noticed that we were the only user of pgd_huge(). So yeah I think it can be removed from core mm, but I'll leave that up to the mm folks. There are already some other changes in that area in flight that could conflict if I try to do more extensive changes in this series. cheers
Michael Ellerman <mpe@ellerman.id.au> writes: > > On powerpc there are two ways for huge pages to be represented in the > top level page table, aka PGD (Page Global Directory). > > If the address space mapped by an individual PGD entry does not > correspond to a given huge page size, then the PGD entry points to a > non-standard page table, known as a "hugepd" (Huge Page Directory). > The hugepd contains some number of huge page PTEs sufficient to map the > address space with the given huge page size. > > On the other hand, if the address space mapped by an individual PGD > entry does correspond exactly to a given huge page size, that PGD entry > is used to directly encode the huge page PTE in place. In this case the > pgd_huge() wrapper indicates to generic code that the PGD entry is > actually a huge page PTE. > > This commit deals with the pgd_huge() case only, it does nothing with > respect to the hugepd case. > > Over time the size of the virtual address space supported on powerpc has > increased several times, which means the location at which huge pages > can sit in the tree has also changed. There have also been new huge page > sizes added, with the introduction of the Radix MMU. > > On Power9 and later with the Radix MMU, the largest huge page size in > any implementation is 1GB. > > Since the introduction of Radix, 1GB entries have been supported at the > PUD level, with both 4K and 64K base page size. Radix has never had a > supported huge page size at the PGD level. > > On Power8 or earlier, which uses the Hash MMU, or Power9 or later with > the Hash MMU enabled, the largest huge page size is 16GB. > > Using the Hash MMU and a base page size of 4K, 16GB has never been a > supported huge page size at the PGD level, due to the geometry being > incompatible. The two supported huge page sizes (16M & 16GB) both use > the hugepd format. > > Using the Hash MMU and a base page size of 64K, 16GB pages were > supported in the past at the PGD level. > > However in commit ba95b5d03596 ("powerpc/mm/book3s/64: Rework page table > geometry for lower memory usage") the page table layout was reworked to > shrink the size of the PGD. > > As a result the 16GB page size now fits at the PUD level when using 64K > base page size. > > Therefore there are no longer any supported configurations where > pgd_huge() can be true, so drop the definitions for pgd_huge(), and > fallback to the generic definition which is always false. > Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> > Fixes: ba95b5d03596 ("powerpc/mm/book3s/64: Rework page table geometry for lower memory usage") > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> > --- > arch/powerpc/include/asm/book3s/64/pgtable-4k.h | 10 ---------- > arch/powerpc/include/asm/book3s/64/pgtable-64k.h | 9 --------- > 2 files changed, 19 deletions(-) > > diff --git a/arch/powerpc/include/asm/book3s/64/pgtable-4k.h b/arch/powerpc/include/asm/book3s/64/pgtable-4k.h > index 4e697bc2f4cd..48f21820afe2 100644 > --- a/arch/powerpc/include/asm/book3s/64/pgtable-4k.h > +++ b/arch/powerpc/include/asm/book3s/64/pgtable-4k.h > @@ -26,16 +26,6 @@ static inline int pud_huge(pud_t pud) > return 0; > } > > -static inline int pgd_huge(pgd_t pgd) > -{ > - /* > - * leaf pte for huge page > - */ > - if (radix_enabled()) > - return !!(pgd_raw(pgd) & cpu_to_be64(_PAGE_PTE)); > - return 0; > -} > -#define pgd_huge pgd_huge > /* > * With radix , we have hugepage ptes in the pud and pmd entries. We don't > * need to setup hugepage directory for them. Our pte and page directory format > diff --git a/arch/powerpc/include/asm/book3s/64/pgtable-64k.h b/arch/powerpc/include/asm/book3s/64/pgtable-64k.h > index 34d1018896b3..2fce3498b000 100644 > --- a/arch/powerpc/include/asm/book3s/64/pgtable-64k.h > +++ b/arch/powerpc/include/asm/book3s/64/pgtable-64k.h > @@ -30,15 +30,6 @@ static inline int pud_huge(pud_t pud) > return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PTE)); > } > > -static inline int pgd_huge(pgd_t pgd) > -{ > - /* > - * leaf pte for huge page > - */ > - return !!(pgd_raw(pgd) & cpu_to_be64(_PAGE_PTE)); > -} > -#define pgd_huge pgd_huge > - > /* > * With 64k page size, we have hugepage ptes in the pgd and pmd entries. We don't > * need to setup hugepage directory for them. Our pte and page directory format > -- > 2.37.2
On Sat, 3 Sep 2022 22:36:39 +1000, Michael Ellerman wrote: > On powerpc there are two ways for huge pages to be represented in the > top level page table, aka PGD (Page Global Directory). > > If the address space mapped by an individual PGD entry does not > correspond to a given huge page size, then the PGD entry points to a > non-standard page table, known as a "hugepd" (Huge Page Directory). > The hugepd contains some number of huge page PTEs sufficient to map the > address space with the given huge page size. > > [...] Applied to powerpc/next. [1/2] powerpc/mm/64s: Drop pgd_huge() https://git.kernel.org/powerpc/c/51da853e3708852f47cd95e6f5e1821c3d54c3ef [2/2] powerpc/mm/64s: Drop p4d_leaf() https://git.kernel.org/powerpc/c/79c5640ab4460a03535ce0f120193174e7701b65 cheers
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable-4k.h b/arch/powerpc/include/asm/book3s/64/pgtable-4k.h index 4e697bc2f4cd..48f21820afe2 100644 --- a/arch/powerpc/include/asm/book3s/64/pgtable-4k.h +++ b/arch/powerpc/include/asm/book3s/64/pgtable-4k.h @@ -26,16 +26,6 @@ static inline int pud_huge(pud_t pud) return 0; } -static inline int pgd_huge(pgd_t pgd) -{ - /* - * leaf pte for huge page - */ - if (radix_enabled()) - return !!(pgd_raw(pgd) & cpu_to_be64(_PAGE_PTE)); - return 0; -} -#define pgd_huge pgd_huge /* * With radix , we have hugepage ptes in the pud and pmd entries. We don't * need to setup hugepage directory for them. Our pte and page directory format diff --git a/arch/powerpc/include/asm/book3s/64/pgtable-64k.h b/arch/powerpc/include/asm/book3s/64/pgtable-64k.h index 34d1018896b3..2fce3498b000 100644 --- a/arch/powerpc/include/asm/book3s/64/pgtable-64k.h +++ b/arch/powerpc/include/asm/book3s/64/pgtable-64k.h @@ -30,15 +30,6 @@ static inline int pud_huge(pud_t pud) return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PTE)); } -static inline int pgd_huge(pgd_t pgd) -{ - /* - * leaf pte for huge page - */ - return !!(pgd_raw(pgd) & cpu_to_be64(_PAGE_PTE)); -} -#define pgd_huge pgd_huge - /* * With 64k page size, we have hugepage ptes in the pgd and pmd entries. We don't * need to setup hugepage directory for them. Our pte and page directory format
On powerpc there are two ways for huge pages to be represented in the top level page table, aka PGD (Page Global Directory). If the address space mapped by an individual PGD entry does not correspond to a given huge page size, then the PGD entry points to a non-standard page table, known as a "hugepd" (Huge Page Directory). The hugepd contains some number of huge page PTEs sufficient to map the address space with the given huge page size. On the other hand, if the address space mapped by an individual PGD entry does correspond exactly to a given huge page size, that PGD entry is used to directly encode the huge page PTE in place. In this case the pgd_huge() wrapper indicates to generic code that the PGD entry is actually a huge page PTE. This commit deals with the pgd_huge() case only, it does nothing with respect to the hugepd case. Over time the size of the virtual address space supported on powerpc has increased several times, which means the location at which huge pages can sit in the tree has also changed. There have also been new huge page sizes added, with the introduction of the Radix MMU. On Power9 and later with the Radix MMU, the largest huge page size in any implementation is 1GB. Since the introduction of Radix, 1GB entries have been supported at the PUD level, with both 4K and 64K base page size. Radix has never had a supported huge page size at the PGD level. On Power8 or earlier, which uses the Hash MMU, or Power9 or later with the Hash MMU enabled, the largest huge page size is 16GB. Using the Hash MMU and a base page size of 4K, 16GB has never been a supported huge page size at the PGD level, due to the geometry being incompatible. The two supported huge page sizes (16M & 16GB) both use the hugepd format. Using the Hash MMU and a base page size of 64K, 16GB pages were supported in the past at the PGD level. However in commit ba95b5d03596 ("powerpc/mm/book3s/64: Rework page table geometry for lower memory usage") the page table layout was reworked to shrink the size of the PGD. As a result the 16GB page size now fits at the PUD level when using 64K base page size. Therefore there are no longer any supported configurations where pgd_huge() can be true, so drop the definitions for pgd_huge(), and fallback to the generic definition which is always false. Fixes: ba95b5d03596 ("powerpc/mm/book3s/64: Rework page table geometry for lower memory usage") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> --- arch/powerpc/include/asm/book3s/64/pgtable-4k.h | 10 ---------- arch/powerpc/include/asm/book3s/64/pgtable-64k.h | 9 --------- 2 files changed, 19 deletions(-)