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

On Fri, Jan 23, 2026 at 12:08:07PM -0800, Yang Shi wrote:

On 1/22/26 6:40 PM, Anshuman Khandual wrote:

quoted

On 22/01/26 7:47 PM, Will Deacon wrote:

quoted

On Thu, Jan 22, 2026 at 10:39:25AM +0530, Anshuman Khandual wrote:

quoted

Hello Yang,

On 07/01/26 5:59 AM, Yang Shi wrote:

quoted

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.

I guess the direct mapping here refers to linear map ? IIUC it is called
direct map on x86 and linear map on arm64 platforms. Then should not it
be renamed as s/DirectMap/LinearMap instead ? This will align with names
from ptdump as well.

Before the above mentioned commit, linear could get altered with memory
hotplug and remove events as well.

quoted

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

If /proc/meminfo interface is getting updated via  arch_report_meminfo()
why not add stats for all kernel virtual address space ranges including
vmemmap, vmalloc etc aka all address range headers in ptdump as many of
those could change during system runtime. What makes linear mapping any
special ?

tbh, I think compatability with x86 is a good argument in this case and
so the naming and formatting proposed by this patch makes sense to me.

Fair enough. Probably adding a comment above arch_report_meminfo() along
with the commit message, explaining the above rationale would be helpful
for developers to understand/recollect this equivalence later on.

quoted

I'm also not sure that it's particularly interesting to see these
rolled-up numbers for the vmalloc area. You really want information
about the area, so extending /proc/vmallocinfo to give information
about the granule size for each entry might be useful but I don't think
it should be part of this patch.

Agreed - vmalloc has a separate file for its details which can be improved
later to accommodate rolled-up numbers. But what about vmemmap ? It always
gets updated along with linear map during memory hotplug and remove events.
Should that be included here ?

The granule size of vmemmap should be quite static IIUC. AFAIK kernel
doesn't modify vmemmap page tables except HVO, but arm64 doesn't support
HVO. And just 4K page size can have PMD mapped vmemmap. It doesn't use
contiguous mapping either. The smallest granularity of memory hotplug is
128M with 4K page size, so vmemmap for hotplugged memory should be PMD
mapped as well.

It might be worth showing the memory consumed by vmemmap for hotplug memory
so that the users can know where the memory is used. The vmemmap used for
bootmem is not counted in MemTotal of /proc/meminfo. But it sounds more core
mm generic and shouldn't be part of this patch IMHO.

Agreed, I don't understand what the granularity of the vmemmap has to do
with this.

Will