[PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Michael Ellerman]

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

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

[PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Michael Ellerman]

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

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

[PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Michael Ellerman]

Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
PGD. So P4D entries are actually PGD entries, or vice versa.

The other way to think of it is that the P4D is a single entry page
table below the PGD. Zero bits of the address are needed to index into
the P4D, therefore a P4D entry maps the same size address space as a PGD
entry.

As explained in the previous commit, there are no huge page sizes
supported directly at the PGD level on 64-bit Book3S, so there are also
no huge page sizes supported at the P4D level.

Therefore p4d_is_leaf() can never be true, so drop the definition and
fallback to the default implementation that always returns false.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 486902aff040..057254063e88 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1459,12 +1459,5 @@ static inline bool pud_is_leaf(pud_t pud)
 	return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PTE));
 }
 
-#define p4d_is_leaf p4d_is_leaf
-#define p4d_leaf p4d_is_leaf
-static inline bool p4d_is_leaf(p4d_t p4d)
-{
-	return !!(p4d_raw(p4d) & cpu_to_be64(_PAGE_PTE));
-}
-
 #endif /* __ASSEMBLY__ */
 #endif /* _ASM_POWERPC_BOOK3S_64_PGTABLE_H_ */
-- 
2.37.2

[PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Michael Ellerman]

Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
PGD. So P4D entries are actually PGD entries, or vice versa.

The other way to think of it is that the P4D is a single entry page
table below the PGD. Zero bits of the address are needed to index into
the P4D, therefore a P4D entry maps the same size address space as a PGD
entry.

As explained in the previous commit, there are no huge page sizes
supported directly at the PGD level on 64-bit Book3S, so there are also
no huge page sizes supported at the P4D level.

Therefore p4d_is_leaf() can never be true, so drop the definition and
fallback to the default implementation that always returns false.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 486902aff040..057254063e88 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1459,12 +1459,5 @@ static inline bool pud_is_leaf(pud_t pud)
 	return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PTE));
 }
 
-#define p4d_is_leaf p4d_is_leaf
-#define p4d_leaf p4d_is_leaf
-static inline bool p4d_is_leaf(p4d_t p4d)
-{
-	return !!(p4d_raw(p4d) & cpu_to_be64(_PAGE_PTE));
-}
-
 #endif /* __ASSEMBLY__ */
 #endif /* _ASM_POWERPC_BOOK3S_64_PGTABLE_H_ */
-- 
2.37.2

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Christophe Leroy]

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

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Christophe Leroy]

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

Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Christophe Leroy]

Le 03/09/2022 à 14:36, Michael Ellerman a écrit :
> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
> PGD. So P4D entries are actually PGD entries, or vice versa.
> 
> The other way to think of it is that the P4D is a single entry page
> table below the PGD. Zero bits of the address are needed to index into
> the P4D, therefore a P4D entry maps the same size address space as a PGD
> entry.
> 
> As explained in the previous commit, there are no huge page sizes
> supported directly at the PGD level on 64-bit Book3S, so there are also
> no huge page sizes supported at the P4D level.
> 
> Therefore p4d_is_leaf() can never be true, so drop the definition and
> fallback to the default implementation that always returns false.

Then here as well, you are removing the only architecture which 
implements a non 'always false' version of p4d_leaf().

x86 has on that is always false:

#define p4d_leaf	p4d_large
static inline int p4d_large(p4d_t p4d)
{
	/* No 512 GiB pages yet */
	return 0;
}

So, should it be dropped as well and all uses removed from core mm ?

Christophe

Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Christophe Leroy]

Le 03/09/2022 à 14:36, Michael Ellerman a écrit :
> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
> PGD. So P4D entries are actually PGD entries, or vice versa.
> 
> The other way to think of it is that the P4D is a single entry page
> table below the PGD. Zero bits of the address are needed to index into
> the P4D, therefore a P4D entry maps the same size address space as a PGD
> entry.
> 
> As explained in the previous commit, there are no huge page sizes
> supported directly at the PGD level on 64-bit Book3S, so there are also
> no huge page sizes supported at the P4D level.
> 
> Therefore p4d_is_leaf() can never be true, so drop the definition and
> fallback to the default implementation that always returns false.

Then here as well, you are removing the only architecture which 
implements a non 'always false' version of p4d_leaf().

x86 has on that is always false:

#define p4d_leaf	p4d_large
static inline int p4d_large(p4d_t p4d)
{
	/* No 512 GiB pages yet */
	return 0;
}

So, should it be dropped as well and all uses removed from core mm ?

Christophe

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Michael Ellerman]

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

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Michael Ellerman]

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

Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Michael Ellerman]

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 03/09/2022 à 14:36, Michael Ellerman a écrit :
>> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
>> PGD. So P4D entries are actually PGD entries, or vice versa.
>> 
>> The other way to think of it is that the P4D is a single entry page
>> table below the PGD. Zero bits of the address are needed to index into
>> the P4D, therefore a P4D entry maps the same size address space as a PGD
>> entry.
>> 
>> As explained in the previous commit, there are no huge page sizes
>> supported directly at the PGD level on 64-bit Book3S, so there are also
>> no huge page sizes supported at the P4D level.
>> 
>> Therefore p4d_is_leaf() can never be true, so drop the definition and
>> fallback to the default implementation that always returns false.
>
> Then here as well, you are removing the only architecture which 
> implements a non 'always false' version of p4d_leaf().
>
> x86 has on that is always false:
>
> #define p4d_leaf	p4d_large
> static inline int p4d_large(p4d_t p4d)
> {
> 	/* No 512 GiB pages yet */
> 	return 0;
> }
>
> So, should it be dropped as well and all uses removed from core mm ?

Probably?

I see very few uses of p4d_leaf(), so I suspect it's not actually being
called in all the places it should be if it ever returned true. See eg.
follow_p4d_mask() which doesn't call it.

I think it would be best to remove it and if anyone ever implements huge
pages at that level (unlikely?) they will need to go back and add
support in the right places.

But ultimately it's up to the mm folks to decide IMHO.

cheers

Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Michael Ellerman]

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 03/09/2022 à 14:36, Michael Ellerman a écrit :
>> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
>> PGD. So P4D entries are actually PGD entries, or vice versa.
>> 
>> The other way to think of it is that the P4D is a single entry page
>> table below the PGD. Zero bits of the address are needed to index into
>> the P4D, therefore a P4D entry maps the same size address space as a PGD
>> entry.
>> 
>> As explained in the previous commit, there are no huge page sizes
>> supported directly at the PGD level on 64-bit Book3S, so there are also
>> no huge page sizes supported at the P4D level.
>> 
>> Therefore p4d_is_leaf() can never be true, so drop the definition and
>> fallback to the default implementation that always returns false.
>
> Then here as well, you are removing the only architecture which 
> implements a non 'always false' version of p4d_leaf().
>
> x86 has on that is always false:
>
> #define p4d_leaf	p4d_large
> static inline int p4d_large(p4d_t p4d)
> {
> 	/* No 512 GiB pages yet */
> 	return 0;
> }
>
> So, should it be dropped as well and all uses removed from core mm ?

Probably?

I see very few uses of p4d_leaf(), so I suspect it's not actually being
called in all the places it should be if it ever returned true. See eg.
follow_p4d_mask() which doesn't call it.

I think it would be best to remove it and if anyone ever implements huge
pages at that level (unlikely?) they will need to go back and add
support in the right places.

But ultimately it's up to the mm folks to decide IMHO.

cheers

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Aneesh Kumar K.V]

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

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Aneesh Kumar K.V]

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

Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Aneesh Kumar K.V]

Michael Ellerman <mpe@ellerman.id.au> writes:

>
> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
> PGD. So P4D entries are actually PGD entries, or vice versa.
>
> The other way to think of it is that the P4D is a single entry page
> table below the PGD. Zero bits of the address are needed to index into
> the P4D, therefore a P4D entry maps the same size address space as a PGD
> entry.
>
> As explained in the previous commit, there are no huge page sizes
> supported directly at the PGD level on 64-bit Book3S, so there are also
> no huge page sizes supported at the P4D level.
>
> Therefore p4d_is_leaf() can never be true, so drop the definition and
> fallback to the default implementation that always returns false.
>

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>

> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
>  arch/powerpc/include/asm/book3s/64/pgtable.h | 7 -------
>  1 file changed, 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 486902aff040..057254063e88 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -1459,12 +1459,5 @@ static inline bool pud_is_leaf(pud_t pud)
>  	return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PTE));
>  }
>  
> -#define p4d_is_leaf p4d_is_leaf
> -#define p4d_leaf p4d_is_leaf
> -static inline bool p4d_is_leaf(p4d_t p4d)
> -{
> -	return !!(p4d_raw(p4d) & cpu_to_be64(_PAGE_PTE));
> -}
> -
>  #endif /* __ASSEMBLY__ */
>  #endif /* _ASM_POWERPC_BOOK3S_64_PGTABLE_H_ */
> -- 
> 2.37.2

Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()

[Aneesh Kumar K.V]

Michael Ellerman <mpe@ellerman.id.au> writes:

>
> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
> PGD. So P4D entries are actually PGD entries, or vice versa.
>
> The other way to think of it is that the P4D is a single entry page
> table below the PGD. Zero bits of the address are needed to index into
> the P4D, therefore a P4D entry maps the same size address space as a PGD
> entry.
>
> As explained in the previous commit, there are no huge page sizes
> supported directly at the PGD level on 64-bit Book3S, so there are also
> no huge page sizes supported at the P4D level.
>
> Therefore p4d_is_leaf() can never be true, so drop the definition and
> fallback to the default implementation that always returns false.
>

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>

> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
>  arch/powerpc/include/asm/book3s/64/pgtable.h | 7 -------
>  1 file changed, 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 486902aff040..057254063e88 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -1459,12 +1459,5 @@ static inline bool pud_is_leaf(pud_t pud)
>  	return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PTE));
>  }
>  
> -#define p4d_is_leaf p4d_is_leaf
> -#define p4d_leaf p4d_is_leaf
> -static inline bool p4d_is_leaf(p4d_t p4d)
> -{
> -	return !!(p4d_raw(p4d) & cpu_to_be64(_PAGE_PTE));
> -}
> -
>  #endif /* __ASSEMBLY__ */
>  #endif /* _ASM_POWERPC_BOOK3S_64_PGTABLE_H_ */
> -- 
> 2.37.2

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Michael Ellerman]

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

Re: [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge()

[Michael Ellerman]

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