Message-ID: <1d9e2eff-c6c9-414d-9e39-e046fc0fdc16@os.amperecomputing.com>
Date: Fri, 23 Jan 2026 12:08:07 -0800
From: Yang Shi <yang@...amperecomputing.com>
To: Anshuman Khandual <anshuman.khandual@....com>,
 Will Deacon <will@...nel.org>
Cc: catalin.marinas@....com, ryan.roberts@....com, cl@...two.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [v5 PATCH] arm64: mm: show direct mapping use in /proc/meminfo



On 1/22/26 6:40 PM, Anshuman Khandual wrote:
>
> 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 ?

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.

Thanks,
Yang

Powered by blists - more mailing lists