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 8C3A4C4167D for ; Thu, 14 Dec 2023 13:02:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 202B46B0697; Thu, 14 Dec 2023 08:02:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18AC06B0698; Thu, 14 Dec 2023 08:02:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0533B6B0699; Thu, 14 Dec 2023 08:02:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E766A6B0697 for ; Thu, 14 Dec 2023 08:02:09 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BCCAFA02C0 for ; Thu, 14 Dec 2023 13:02:09 +0000 (UTC) X-FDA: 81565436778.13.F302230 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf26.hostedemail.com (Postfix) with ESMTP id 67179140042 for ; Thu, 14 Dec 2023 13:02:06 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702558926; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vHjArmIPYKo0W+kRZwahCITqBVoiDCxdE8zmLzodLXg=; b=ov5Ey/XeQwD+6gBNr8+n9W+3WMtKkKkg9MUj082uIAEIU/Lkx9/Oqv1YbwfIxw5B7Dn6aS wWFrNNkftkFN06Zd/B7XptMbBeppuDfIbnwUA94Cb0euhwp9jliWw8egkRiflp/r4KQy9h Ze/2PQU+tFawa/VmKKw2tCo9UCEM1e4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702558926; a=rsa-sha256; cv=none; b=IJmPPy+SD3fOwuGyJAQ2s/feknyABk7bhat6P4zGL6evC4ydqORWJuYU+qJ6BOXxsIFoD7 ho1fd169MkTIkxb2YBchxd5A92mdipDDvo1ihEWNahcY6GAauC69kQsI4hpjU/wgXgZes2 YxOqFD2JCusQdCEcjSrDbAZIWqlIHW8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=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 D7297C15; Thu, 14 Dec 2023 05:02:50 -0800 (PST) Received: from [10.57.86.13] (unknown [10.57.86.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C667E3F5A1; Thu, 14 Dec 2023 05:02:03 -0800 (PST) Message-ID: Date: Thu, 14 Dec 2023 13:02:00 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ARM64: Implement arch_report_meminfo() Content-Language: en-GB To: "Christoph Lameter (Ampere)" , Catalin Marinas , Marc Zyngier , Will Deacon , Ryan Roberts , Mark Rutland , Vishal Moola Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org References: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org> From: Robin Murphy In-Reply-To: <79f9a0ad-80cc-1fc5-2d48-cc5ba82bd844@gentwo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 67179140042 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: imoz96mwn4nuqtp4b145ahhica19pu1e X-HE-Tag: 1702558926-727049 X-HE-Meta: U2FsdGVkX18jaCRTSig/Udsna2p/XiejXvk/Q0+iIA0lWIcBa63L8cG3L4R8mXcOyAUNCKfHWpgVFHtzPBIfdSa3ufi89MZyxq2tNkNRmr1wffCWrqiPxRXA3vXEMF+2wrZFjB9NIf5Ch+DOezelE+/alzGj4DjncBtK8J+W59MUGeGkUjr4y4LayiA8Iqs0CAHfVt8dzcbHmm7wbrqLzsy1Ox92c1TaalfJLN4iFNQXijDT5iqHwui/Zsm1pHJUGcQe5ZOBgMnXn8fcHKthO+XQ8BdIZe6fVuZcVrBkK8E79q98q/Eqz1yfgo+5upjRPyH4wW7hpY/HEYDwf+T6Q23i5xn9MNWkdhCAYGVwlviiSyoXZ/vPnBnfYFR5HIZVU5IJBRAMWmWFCRp9EXiIQHyo+6mZim9Xi/Ncc+4aI8ncqZIdnIzUjSXzAi0Y66hwt6G2ZOAvmsm++2o7SLlacSDRwuLdSHjULHaJUX+FrIwLbl4JGUu2fvkemlOPiatJALSK/AbORfZj0DesqJDyeoIQ1tNt0FdM6wJCuXfQrNeaeoHhwYVBuOsDbg40ufxETzZL8byhFPDoES9jQXKg2stJ5xqHph5wjI/wPjuFdf684Kez+GQpLotrKxvjs32knQ+AGwOTFPje1FJ+k5fWQFQrmKF0bW6qkDNbkTeBUw71MTrqbCCKYi9cN3rQ3VA+yyLGoX75oPvFAfMHXXTAaiYvXa27MQLdmNPNtZTarbrUXfUBaLPNYFMN0XcUe4OhxB/g3hpPijUAdpDpBzUCJbm8laelZRVK9EZp9RLv4bGP0NZroLOxqOCp2oSeq4GhUuaHnH01OcX0cJ3AP+RzBHDpJ8I276erYrQ2d7/hNfdc7wCbmxzv9nRWa6KL94JH0Qv3t4KAiRzYCpqJBbSgvow4OsLRyYCpPT9W6BaoEkiG80MOycCF+0VjrDJyTBbXWZAt29GXzB+7Y+ZP0nP j3jJsAmP nz7MFal8mUVdz4agnRYSxzxkDgr4C5E7SlEI+29XJtSMR0GXO883bwQdHqfe1KnHsD2ViauSkis8VzuvRsH738SGIunSByuY6ZrBYRC8c/dSs+NUkw3LqCB68pf1w6XNk9Yyrg+6cud4Mee3cieydjK3b0E7NyH+C6FfegpK4eZc5ZChtCsRYR8l8sHKil1IG7UYR79kl3vBROjiyV19KvkCYSJ8iHVsVSbX3DnlV6c3stkABHXatcPp26NZho4CF16JFyhWUNKfyzwVLFHcrTSFjvtkGtMhuyBLbT7x/WF369HhT1AijXKJa7wlu88oddVDvdUfgAiaKVbXtOCLGYpfUXGFD45k4ivdJnlb3K2fc70d9pjFoT8pjw4VQsGcsxAHY 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 2023-12-08 9:11 pm, Christoph Lameter (Ampere) wrote: > X86 has information in /proc/meminfo showing the use of large mappings > for the kernel direct map. This has now also become important for > ARM since the kernel default CONFIG_RODATA_FULL_DEFAULT_ENABLED > forces 4K PTE use for the direct map and users may not be aware > of the performance impact of the increased TLB use etc. > > The output of /proc/meminfo on ARM64 is then after this patch: > > 4K page size: > > Hugepagesize:       2048 kB > Hugetlb:               0 kB > DirectMap4k:      155912 kB > CONT DMap4k:        1176 kB > DirectMap2M:      722944 kB > CONT DMap2M:       28672 kB > DirectMap1G:   534773760 kB > > 64K page size: > > Hugepagesize:     524288 kB > Hugetlb:               0 kB > DirectMap64k:      882624 kB > CONT DMap64k:       19904 kB > DirectMap512M:    534773760 kB > CONT DMap512M:           0 kB > DirectMap4096G:           0 kB > > Signed-off-by: Christoph Lameter > > Index: linux/arch/arm64/mm/mmu.c > =================================================================== > --- linux.orig/arch/arm64/mm/mmu.c > +++ linux/arch/arm64/mm/mmu.c > @@ -66,6 +66,12 @@ u32 __boot_cpu_mode[] = { BOOT_CPU_MODE_ >   */ >  long __section(".mmuoff.data.write") __early_cpu_boot_status; > > +static atomic_t nr_pte; > +static atomic_t nr_pmd; > +static atomic_t nr_pud; > +static atomic_t nr_pte_cont; > +static atomic_t nr_pmd_cont; > + >  /* >   * Empty_zero_page is a special page that is used for zero-initialized > data >   * and COW. > @@ -179,6 +185,7 @@ static void init_pte(pmd_t *pmdp, unsign >          pte_t old_pte = READ_ONCE(*ptep); > >          set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot)); > +        atomic_inc(&nr_pte); > >          /* >           * After the PTE entry has been populated once, we > @@ -223,8 +230,10 @@ static void alloc_init_cont_pte(pmd_t *p > >          /* use a contiguous mapping if the range is suitably aligned */ >          if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) && > -            (flags & NO_CONT_MAPPINGS) == 0) > +            (flags & NO_CONT_MAPPINGS) == 0) { >              __prot = __pgprot(pgprot_val(prot) | PTE_CONT); > +            atomic_inc(&nr_pte_cont); > +        } > >          init_pte(pmdp, addr, next, phys, __prot); > > @@ -249,6 +258,7 @@ static void init_pmd(pud_t *pudp, unsign >          if (((addr | next | phys) & ~PMD_MASK) == 0 && >              (flags & NO_BLOCK_MAPPINGS) == 0) { >              pmd_set_huge(pmdp, phys, prot); > +            atomic_inc(&nr_pmd); > >              /* >               * After the PMD entry has been populated once, we > @@ -301,8 +311,10 @@ static void alloc_init_cont_pmd(pud_t *p > >          /* use a contiguous mapping if the range is suitably aligned */ >          if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) && > -            (flags & NO_CONT_MAPPINGS) == 0) > +            (flags & NO_CONT_MAPPINGS) == 0) { >              __prot = __pgprot(pgprot_val(prot) | PTE_CONT); > +            atomic_inc(&nr_pmd_cont); > +        } > >          init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags); > > @@ -346,7 +358,7 @@ static void alloc_init_pud(pgd_t *pgdp, >             ((addr | next | phys) & ~PUD_MASK) == 0 && >              (flags & NO_BLOCK_MAPPINGS) == 0) { >              pud_set_huge(pudp, phys, prot); > - > +            atomic_inc(&nr_pud); 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. Thanks, Robin. >              /* >               * After the PUD entry has been populated once, we >               * only allow updates to the permission attributes. > @@ -1486,3 +1498,35 @@ void ptep_modify_prot_commit(struct vm_a >  { >      set_pte_at(vma->vm_mm, addr, ptep, pte); >  } > + > +#ifdef CONFIG_PROC_FS > +void arch_report_meminfo(struct seq_file *m) > +{ > +    unsigned long pagesize_in_kb = PAGE_SIZE / 1024; > + > +    seq_printf(m, "DirectMap%luk:    %8lu kB\n", > +            pagesize_in_kb, > +              (unsigned long)atomic_read(&nr_pte) * pagesize_in_kb); > + > +        seq_printf(m, "CONT DMap%luk:    %8lu kB\n", > +            pagesize_in_kb, > +            (unsigned long)atomic_read(&nr_pte_cont) * pagesize_in_kb); > + > +    pagesize_in_kb = PMD_SIZE / 1024; > + > +        seq_printf(m, "DirectMap%luM:    %8lu kB\n", > +            pagesize_in_kb / 1024, > +            (unsigned long)atomic_read(&nr_pmd) * pagesize_in_kb); > + > +    seq_printf(m, "CONT DMap%luM:    %8lu kB\n", > +            pagesize_in_kb / 1024, > +            (unsigned long)atomic_read(&nr_pmd_cont) * pagesize_in_kb); > + > +    pagesize_in_kb = PUD_SIZE / 1024; > + > +    seq_printf(m, "DirectMap%luG:  %10lu kB\n", > +                   pagesize_in_kb >> 20, > +                        (unsigned long)atomic_read(&nr_pud) * > pagesize_in_kb); > +} > +#endif > + > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel