From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45D1DC35274 for ; Mon, 18 Dec 2023 17:50:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D96A66B009C; Mon, 18 Dec 2023 12:50:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D46D76B009D; Mon, 18 Dec 2023 12:50:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0EF16B009E; Mon, 18 Dec 2023 12:50:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AB2546B009C for ; Mon, 18 Dec 2023 12:50:02 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 469561A025C for ; Mon, 18 Dec 2023 17:50:02 +0000 (UTC) X-FDA: 81580677444.05.E930382 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf18.hostedemail.com (Postfix) with ESMTP id 243AC1C002A for ; Mon, 18 Dec 2023 17:49:58 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=softfail (imf18.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702921799; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ubBMLC8E1HGZWxBQDmH7bSaxm2kP/gj6aXhQxYOX0DU=; b=vRknLMhJexcQxCt/rj3y5It9pw8dKsWfCXAkWUn9tl6NM36ieUUGoPq3HWEd8CsuQNvwzW PaDHCMkjqCcI7httDOUpP7WVVnP6JfJZpTHfhyYDtaKVabBr5Rg7pWcc+Vu/iuhWiCcU/r yHZsq4DreowoOd7kutdJHvMyzWXPcUQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=softfail (imf18.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702921799; a=rsa-sha256; cv=none; b=MaCl8u9aBeZE+zhVrlJRp0e9QjTnen2BWePPQNfitRsA8ZZJ/UsELcmMNYIbHIXyaR11F9 EVF1lJRgkhrn7SglaPmSwkt0Y6ao5fHBFSeq5p5I4Ad89De7br5i+Ba6J2kqZCHexw5P4G KRRSrQbR5eyZ6sShYhbhnLW+UcOECvE= Received: by gentwo.org (Postfix, from userid 1003) id B62C440E9A; Mon, 18 Dec 2023 09:49:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id B4FF840E94; Mon, 18 Dec 2023 09:49:57 -0800 (PST) Date: Mon, 18 Dec 2023 09:49:57 -0800 (PST) From: "Christoph Lameter (Ampere)" To: Robin Murphy cc: Catalin Marinas , Marc Zyngier , Will Deacon , Ryan Roberts , Mark Rutland , Vishal Moola , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH] ARM64: Implement arch_report_meminfo() In-Reply-To: <1a8ef5e3-e478-492f-8f4d-05cc16945593@arm.com> Message-ID: References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org> <1a8ef5e3-e478-492f-8f4d-05cc16945593@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 243AC1C002A X-Rspam-User: X-Stat-Signature: 84whwea5e4wpazjhruafhdmbnu3dkh3b X-Rspamd-Server: rspam01 X-HE-Tag: 1702921798-708999 X-HE-Meta: U2FsdGVkX1/UnpGVKE6VTntUxpU8i6oOs/ztpoMEV6ZSVUEkZ9B0tpQA5rst/X1/4YW+u0Vhudwn0B0UaETgN1HWfE6Zviik9A3OuNgjjL9HN8vw8EWN+sd+Fi5PTk3heD8SSLHUtavWY1FwXuGZQo2lHHAW+iQw9cXKsYVJ/Klx7rm/xs+kLcw7kLvJEeHpQ1S0tEx/LbOL4GAQBvKhEafF3oxEKXYL1I3NoDnQXd1+Xqq1jMzjyWS8eWlySFxeWVT/3sP7Qo01dE/fOvzt9EuSHiulsKYpU/55qXp7p2iOyYPF1wijfRJbB9M6sQ+EsnX+vJvLP5AEOciIK242JQsyicBhjdRIJ+JQ9JNW2k2OXyj8FVOcvEOMhTeOY99ulMkUAlIzqooDZmxawXGZKGRw6Yu7cxfCX+MR6xvVeHp21Mzw1wYh8BT4ugMTLU57QpL5V31grZ3crNl2Imm+8CPw7Q+SyKzxyyCyIOOo4hTW3nmKSFTXxXZmKCGM8vYIuHsamGwHiIVuFGO/awsIWYMuCEoEUSNOdP1aPZYCesuU9wneMyZMLRA96Mr2V8wL/0oDbU++zcyypimYDTuJW6YtckU11WfkMoMDRB1KV2ValPG84jYZgyUHsnZGiFps2iADwvwS7LtlG6yTsog/2calBd8Pq6RFZcBQN64kbpZ4q0lHCsOvph6ook1eF3O5AoykBfTVm1y44gjl9Gc3w11E9cS5bGcFmERfK/roPUiByvR604bXJo1JP+KTp0M6i38WYdhumBVk9rxS+ipcmPHy2I2cYcUhEfXF9fDjSGLsxnUx5esm7bpajjErPtNncboTrxzN7mWziUKz80/GUIGpMF0+jzdMaGCfN/EhfotQKgf6ZmKSDwf+ne+2o4oObS1VxZZWoPoj/tAIC1lu7rfkxi+iGen4Wsad1GCZQPrg/758wRjLLYktZos8gUV4a7dNdY3hiEw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 15 Dec 2023, Robin Murphy wrote: > On 14/12/2023 9:35 pm, Christoph Lameter (Ampere) wrote: >> On Thu, 14 Dec 2023, Robin Murphy wrote: >> >>> It seems somewhat suspect that these counts only ever increase. It's not >>> often that we change or remove parts of the linear map, but it certainly >>> can happen. >> >> Well yes in the case of hotplug I guess ... Ok here is V2 > > There are also paths where we remove and reinstate parts of the linear map > via set_memory_valid(), set_direct_map_*(), and possibly others. If we're > exposing a user ABI that claims to be accounting kernel VA mappings, then I > think users are within their rights to expect it to actually account kernel > VA mappings, not just expose numbers whose only guaranteed significance is > whether they are zero or nonzero. set_memory_valid() changes mappings via __change_memory_common() and apply_to_page_range(). It seems that apply_to_page range() creates PTEs as needed etc. However, I do not see any accounting for direct map modification accounting on x86 either. Since this was satifactory for x86 I dont believe that more is needed. Introducing atomics in potentially performance sensitive functions run when the kernel is up is not that advisable and doing so would require core kernel changes going beyond the enablement of arch_report_meminfo() on ARM64. > Looking again, am I also right in thinking that what I assumed were the > non-contiguous counts here are actually total counts of *either* type of > mapping at that level, and inclusive of the contiguous counts? If so, that > seems a bit non-obvious - my intuitive expectation would be for the sum of > all these numbers to represent the total amount of direct-mapped RAM, where > either we're intersted in each distinct type of mapping and accounting them > all separately, or we're simply interested in the general shape of the > pagetables, and thus would account per-level and ignore the contiguous bit > since we don't know whether it's actually doing anything useful anyweay Yes, the CONT PTEs are a subset of the other counts since they are only a special case of the PTE type. They are important for performance on ARM64 in particular with the anticipated use of them for the various sizes of pages supported in the kernel with the introduction of folios for the page cache. The problem with CONT_PTE is that it is not clear whether the architecture supports it or now. The amount of CONT_PTE can influence the TLB coverage possible in kernel space. We are generally interested in the shape of the page tables. If the user later uses processes that require a degradation through smaller mappings then that is load dependent.