Message-ID: <aXdhvyW1f10YnZx1@willie-the-truck>
Date: Mon, 26 Jan 2026 12:44:47 +0000
From: Will Deacon <will@...nel.org>
To: Yang Shi <yang@...amperecomputing.com>
Cc: Anshuman Khandual <anshuman.khandual@....com>, 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 Fri, Jan 23, 2026 at 12:08:07PM -0800, Yang Shi wrote:
> 
> 
> 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.

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

Will

Powered by blists - more mailing lists