[PATCH] arm64/mm: Rename PGD_SIZE as PGD_TABLE_SIZE

[PATCH] arm64/mm: Rename PGD_SIZE as PGD_TABLE_SIZE

[Anshuman Khandual]

PXD_SIZE represents the virtual address range size covered by a single page
table entry on a given page table level. On arm64 PGD entry address span is
represented with PGDIR_XXX macros instead while PGD_SIZE has been referring
to size of the PGD table itself. So PGD_SIZE has been some what confusing.

Rename PGD_SIZE as PGD_TABLE_SIZE making it explicit that it represents PGD
table size rather than virtual address range covered by a single PGD entry.
While here, also move PGD_TABLE_SIZE inside pgtable-hwdef.h header.

No functional change.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
 arch/arm64/include/asm/pgalloc.h       | 2 --
 arch/arm64/include/asm/pgtable-hwdef.h | 1 +
 arch/arm64/mm/mmu.c                    | 2 +-
 arch/arm64/mm/pgd.c                    | 6 +++---
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 1b4509d3382c..d81df17663ee 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -17,8 +17,6 @@
 #define __HAVE_ARCH_PUD_FREE
 #include <asm-generic/pgalloc.h>
 
-#define PGD_SIZE	(PTRS_PER_PGD * sizeof(pgd_t))
-
 #if CONFIG_PGTABLE_LEVELS > 2
 
 static inline void __pud_populate(pud_t *pudp, phys_addr_t pmdp, pudval_t prot)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index 72f31800c703..241fc749455d 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -83,6 +83,7 @@
 #define PGDIR_SIZE		(_AC(1, UL) << PGDIR_SHIFT)
 #define PGDIR_MASK		(~(PGDIR_SIZE-1))
 #define PTRS_PER_PGD		(1 << (VA_BITS - PGDIR_SHIFT))
+#define PGD_TABLE_SIZE		(PTRS_PER_PGD * sizeof(pgd_t))
 
 /*
  * Contiguous page definitions.
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a25d8beacc83..bd9330fef173 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1356,7 +1356,7 @@ static int __init map_entry_trampoline(void)
 	pgprot_val(prot) &= ~PTE_NG;
 
 	/* Map only the text into the trampoline page table */
-	memset(tramp_pg_dir, 0, PGD_SIZE);
+	memset(tramp_pg_dir, 0, PGD_TABLE_SIZE);
 	early_create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS,
 				 entry_tramp_text_size(), prot,
 				 pgd_pgtable_alloc_init_mm, NO_BLOCK_MAPPINGS);
diff --git a/arch/arm64/mm/pgd.c b/arch/arm64/mm/pgd.c
index bf5110b91e2f..4f7c6416158b 100644
--- a/arch/arm64/mm/pgd.c
+++ b/arch/arm64/mm/pgd.c
@@ -19,7 +19,7 @@ static struct kmem_cache *pgd_cache __ro_after_init;
 
 static bool pgdir_is_page_size(void)
 {
-	if (PGD_SIZE == PAGE_SIZE)
+	if (PGD_TABLE_SIZE == PAGE_SIZE)
 		return true;
 	if (CONFIG_PGTABLE_LEVELS == 4)
 		return !pgtable_l4_enabled();
@@ -56,12 +56,12 @@ void __init pgtable_cache_init(void)
 	 * With 52-bit physical addresses, the architecture requires the
 	 * top-level table to be aligned to at least 64 bytes.
 	 */
-	BUILD_BUG_ON(!IS_ALIGNED(PGD_SIZE, 64));
+	BUILD_BUG_ON(!IS_ALIGNED(PGD_TABLE_SIZE, 64));
 #endif
 
 	/*
 	 * Naturally aligned pgds required by the architecture.
 	 */
-	pgd_cache = kmem_cache_create("pgd_cache", PGD_SIZE, PGD_SIZE,
+	pgd_cache = kmem_cache_create("pgd_cache", PGD_TABLE_SIZE, PGD_TABLE_SIZE,
 				      SLAB_PANIC, NULL);
 }
-- 
2.43.0

Re: [PATCH] arm64/mm: Rename PGD_SIZE as PGD_TABLE_SIZE

[Will Deacon]

On Tue, Jul 14, 2026 at 10:00:50AM +0530, Anshuman Khandual wrote:
> PXD_SIZE represents the virtual address range size covered by a single page
> table entry on a given page table level. On arm64 PGD entry address span is
> represented with PGDIR_XXX macros instead while PGD_SIZE has been referring
> to size of the PGD table itself. So PGD_SIZE has been some what confusing.
> 
> Rename PGD_SIZE as PGD_TABLE_SIZE making it explicit that it represents PGD
> table size rather than virtual address range covered by a single PGD entry.
> While here, also move PGD_TABLE_SIZE inside pgtable-hwdef.h header.
> 
> No functional change.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: David Hildenbrand (Arm) <david@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
>  arch/arm64/include/asm/pgalloc.h       | 2 --
>  arch/arm64/include/asm/pgtable-hwdef.h | 1 +
>  arch/arm64/mm/mmu.c                    | 2 +-
>  arch/arm64/mm/pgd.c                    | 6 +++---
>  4 files changed, 5 insertions(+), 6 deletions(-)

I'm not disagreeing that we have an inconsistency here, but does this
patch series help in any meaningful way? Firstly, folks are probably
pretty used to the current (inconsistent) terminology by now and,
secondly, I think the main problem is that we have both PGDIR* and PGD*
based constants, so adding a PGD_TABLE_SIZE just makes things more
confusing. Worse, this exists even in core code:

  include/linux/pgtable.h:
	#define pgd_index(a)  (((a) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1))

so I would argue that, if you wanted to repaint all of this, that would
be the place to start, not by making the arm64 even weirder.

Personally, though, I'd leave it all alone because I not a big fan of
this sort of churn in isolation.

Will

Re: [PATCH] arm64/mm: Rename PGD_SIZE as PGD_TABLE_SIZE

[Anshuman Khandual]

On 15/07/26 6:26 PM, Will Deacon wrote:
> On Tue, Jul 14, 2026 at 10:00:50AM +0530, Anshuman Khandual wrote:
>> PXD_SIZE represents the virtual address range size covered by a single page
>> table entry on a given page table level. On arm64 PGD entry address span is
>> represented with PGDIR_XXX macros instead while PGD_SIZE has been referring
>> to size of the PGD table itself. So PGD_SIZE has been some what confusing.
>>
>> Rename PGD_SIZE as PGD_TABLE_SIZE making it explicit that it represents PGD
>> table size rather than virtual address range covered by a single PGD entry.
>> While here, also move PGD_TABLE_SIZE inside pgtable-hwdef.h header.
>>
>> No functional change.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: David Hildenbrand (Arm) <david@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>  arch/arm64/include/asm/pgalloc.h       | 2 --
>>  arch/arm64/include/asm/pgtable-hwdef.h | 1 +
>>  arch/arm64/mm/mmu.c                    | 2 +-
>>  arch/arm64/mm/pgd.c                    | 6 +++---
>>  4 files changed, 5 insertions(+), 6 deletions(-)
> 
> I'm not disagreeing that we have an inconsistency here, but does this
> patch series help in any meaningful way? Firstly, folks are probably
> pretty used to the current (inconsistent) terminology by now and,
> secondly, I think the main problem is that we have both PGDIR* and PGD*
> based constants, so adding a PGD_TABLE_SIZE just makes things more
> confusing. Worse, this exists even in core code:
> 
>   include/linux/pgtable.h:
> 	#define pgd_index(a)  (((a) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1))
> 
> so I would argue that, if you wanted to repaint all of this, that would
> be the place to start, not by making the arm64 even weirder.
> 
> Personally, though, I'd leave it all alone because I not a big fan of
> this sort of churn in isolation.

Agreed that PGDIR_SHIFT/SIZE is the true source of this inconsistency
deviating from all other pgtable level's macros expressing an address
range. But this above PGD_SIZE based confusion is specific (but then
well contained) inside arm and arm64 platforms.

Changing PGDIR_[SHIFT|SIZE] on all platforms to PGD_[SHIFT|SIZE] and
then converting arm and arm64 platform's PGD_SIZE as PGDIR_SIZE might
be a better solution. But as suggested will just drop this for now.