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

[Will Deacon]

On Tue, May 19, 2026 at 09:36:57AM -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 at os.amperecomputing.com>
> ---
>  arch/arm64/mm/mmu.c | 192 +++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 171 insertions(+), 21 deletions(-)
> 
> v7: * Rebased to v7.1-rc4
>     * Changed "dm" to "lm" to follow ARM convention per Will
>     * Used __is_lm_alias() instead of reinventing a new helper per Will

Thanks, but Sashiko has pointed out a few nasty issues:

https://sashiko.dev/#/patchset/20260519163657.1259416-1-yang@os.amperecomputing.com

In particular, the potential for races updating the shared counters and
double-accounting of entries due to permission changes look like
interesting things to check.

Will