From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D0ADA37F8DE for ; Fri, 23 Jan 2026 02:40:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769136068; cv=none; b=q0gonme4tVyWRXxM0EWFXhe+NeXI2M1+pQ6SVGtePzbUzVgl4YsAL12bTwyyy99vQnawlC7yi5Ci1jn9/g5wKTARrXsGskWAdbveumAz7wPj3er0pgvg90WyEv83wC1CBuk7kDQCjSX+e+lwsvxAAnGjk7Hxx+cOH3ebgSX9MKk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769136068; c=relaxed/simple; bh=gjhajEdlLApyJ1BJ/kWwcc5Iqc8sGnaT+2s+3BP8YLY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RsOW95B3qfX0M7nV1MOFEMXDvB0FyT24LGON8rECPEXMmRMkzM6BXqUTnHnmvv37+B4LNM9l3kY146mn7EfnU8EtCvvDM6mIX0tV7GW17Z/Oy6d396xqTSTa3zm3KJhQWuMoty47gu/5yAtjdAP1Fdnc7ybCGpGzsk6pmw3UA/k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2DB471476; Thu, 22 Jan 2026 18:40:20 -0800 (PST) Received: from [10.164.18.52] (unknown [10.164.18.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B6B7B3F740; Thu, 22 Jan 2026 18:40:24 -0800 (PST) Message-ID: <8e9f762f-5933-4e30-ab6d-489a56de4eaf@arm.com> Date: Fri, 23 Jan 2026 08:10:21 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v5 PATCH] arm64: mm: show direct mapping use in /proc/meminfo To: Will Deacon Cc: Yang Shi , catalin.marinas@arm.com, ryan.roberts@arm.com, cl@gentwo.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260107002944.2940963-1-yang@os.amperecomputing.com> <965a0b46-f32e-40e6-ab71-211f84d6c3cf@arm.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ?