Re: [v6 PATCH] arm64: mm: show direct mapping use in /proc/meminfo

[Yang Shi]

On 5/12/26 8:22 AM, Will Deacon wrote:
> On Mon, Mar 16, 2026 at 12:29:33PM -0700, Yang Shi wrote:
> > Since commit a166563e7ec3 ("arm64: mm: support large block mapping when
> > rodata=full"), the direct mapping may be split on some machines instead
> > keeping static since boot. It makes more sense to show the direct mapping
> > use in /proc/meminfo than before.
> > This patch will make /proc/meminfo show the direct mapping use like the
> > below (4K base page size):
> > DirectMap4K:       94792 kB
> > DirectMap64K:     134208 kB
> > DirectMap2M:     1173504 kB
> > DirectMap32M:    5636096 kB
> > DirectMap1G:    529530880 kB
> >
> > Although just the machines which support BBML2_NOABORT can split the
> > direct mapping, show it on all machines regardless of BBML2_NOABORT so
> > that the users have consistent view in order to avoid confusion.
> >
> > Although ptdump also can tell the direct map use, but it needs to dump
> > the whole kernel page table. It is costly and overkilling. It is also
> > in debugfs which may not be enabled by all distros. So showing direct
> > map use in /proc/meminfo seems more convenient and has less overhead.
> >
> > Signed-off-by: Yang Shi <yang@xxxxxxxxxxxxxxxxxxxxxx>
> > ---
> > v6: * Rebased to v7.0-rc3
> >      * Rebased on top of Anshuman's v5 "arm64/mm: Enable batched TLB flush
> >        in unmap_hotplug_range()"
> >      * Used const for direct map type array per Will
> >      * Defined PUD size for 16K/64K even though it is not used per Will
> >      * Removed the misleading comment in init_pmd() per Will
> > v5: * Rebased to v6.19-rc4
> >      * Fixed the build error for !CONFIG_PROC_FS
> > v4: * Used PAGE_END instead of _PAGE_END(VA_BITS_MIN) per Ryan
> >      * Used shorter name for the helpers and variables per Ryan
> >      * Fixed accounting for memory hotunplug
> > v3: * Fixed the over-accounting problems per Ryan
> >      * Introduced helpers for add/sub direct map use and #ifdef them with
> >        CONFIG_PROC_FS per Ryan
> >      * v3 is a fix patch on top of v2
> > v2: * Counted in size instead of the number of entries per Ryan
> >      * Removed shift array per Ryan
> >      * Use lower case "k" per Ryan
> >      * Fixed a couple of build warnings reported by kernel test robot
> >      * Fixed a couple of poential miscounts
> >
> >   arch/arm64/mm/mmu.c | 197 +++++++++++++++++++++++++++++++++++++++-----
> >   1 file changed, 176 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 5fb9a66f0754..7e95dbc69d57 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -29,6 +29,7 @@
> >   #include <linux/mm_inline.h>
> >   #include <linux/pagewalk.h>
> >   #include <linux/stop_machine.h>
> > +#include <linux/proc_fs.h>
> >   
> >   #include <asm/barrier.h>
> >   #include <asm/cputype.h>
> > @@ -171,6 +172,87 @@ static void init_clear_pgtable(void *table)
> >   	dsb(ishst);
> >   }
> >   
> > +enum dm_type {
> > +	PTE,
> > +	CONT_PTE,
> > +	PMD,
> > +	CONT_PMD,
> > +	PUD,
> > +	NR_DM_TYPE,
> > +};
> > +
> > +#ifdef CONFIG_PROC_FS
> > +static unsigned long dm_meminfo[NR_DM_TYPE];
> > +
> > +void arch_report_meminfo(struct seq_file *m)
> > +{
> > +	const char *size[NR_DM_TYPE];
> > +
> > +#if defined(CONFIG_ARM64_4K_PAGES)
> > +	size[PTE] = "4k";
> > +	size[CONT_PTE] = "64k";
> > +	size[PMD] = "2M";
> > +	size[CONT_PMD] = "32M";
> > +	size[PUD] = "1G";
> > +#elif defined(CONFIG_ARM64_16K_PAGES)
> > +	size[PTE] = "16k";
> > +	size[CONT_PTE] = "2M";
> > +	size[PMD] = "32M";
> > +	size[CONT_PMD] = "1G";
> > +	size[PUD] = "64G";
> > +#elif defined(CONFIG_ARM64_64K_PAGES)
> > +	size[PTE] = "64k";
> > +	size[CONT_PTE] = "2M";
> > +	size[PMD] = "512M";
> > +	size[CONT_PMD] = "16G";
> > +	size[PUD] = "4T";
> > +#endif
> > +
> > +	seq_printf(m, "DirectMap%s:	%8lu kB\n",
> > +			size[PTE], dm_meminfo[PTE] >> 10);
> > +	seq_printf(m, "DirectMap%s:	%8lu kB\n",
> > +			size[CONT_PTE],
> > +			dm_meminfo[CONT_PTE] >> 10);
> > +	seq_printf(m, "DirectMap%s:	%8lu kB\n",
> > +			size[PMD], dm_meminfo[PMD] >> 10);
> > +	seq_printf(m, "DirectMap%s:	%8lu kB\n",
> > +			size[CONT_PMD],
> > +			dm_meminfo[CONT_PMD] >> 10);
> > +	if (pud_sect_supported())
> > +		seq_printf(m, "DirectMap%s:	%8lu kB\n",
> > +			size[PUD], dm_meminfo[PUD] >> 10);
> > +}
> > +
> > +static inline bool is_dm_addr(unsigned long addr)
> > +{
> > +	return (addr >= PAGE_OFFSET) && (addr < PAGE_END);
> > +}
> Just use __is_lm_address()?

Yeah, good idea.

> For better or worse, the arm64 arch code tends to talk about the "linear
> map" rather than the "direct map", so a little bit of renaming would be
> good (i.e. s/dm/lm/). I'm fine if you want to keep the user-visible
> strings as "DirectMap".

Sure, I will rename the internal APIs to "lm" to keep the consistency. I 
think we'd better to keep the user-visible strings as "DirectMap".

Thanks,
Yang

> Will