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

[Anshuman Khandual <anshuman.khandual@arm.com>]

On 22/01/26 7:47 PM, Will Deacon wrote:
> On Thu, Jan 22, 2026 at 10:39:25AM +0530, Anshuman Khandual wrote:
>> Hello Yang,
>>
>> On 07/01/26 5:59 AM, 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.
>>
>> 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.
>>
>>> 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.

> 
> 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 ?