linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ryan Roberts <ryan.roberts@arm.com>
To: Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Yu Zhao <yuzhao@google.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 2/2] mm: /proc/pid/smaps: Report contpte mappings
Date: Tue, 13 Jun 2023 17:09:50 +0100	[thread overview]
Message-ID: <20230613160950.3554675-3-ryan.roberts@arm.com> (raw)
In-Reply-To: <20230613160950.3554675-1-ryan.roberts@arm.com>

arm64 intends to start using its "contpte" bit in pgtables more
frequently, and therefore it would be useful to know how well utilised
it is in order to help diagnose and fix performance issues.

Add "ContPTEMapped" field, which shows how much of the rss is mapped
using contptes. For architectures that do not support contpte mappings
(as determined by pte_cont() not being defined) the field will be
suppressed.

Rollup Example:

aaaac5150000-ffffccf07000 ---p 00000000 00:00 0                 [rollup]
Rss:               11504 kB
...
ContPTEMapped:      6848 kB

Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
---
 Documentation/filesystems/proc.rst |  5 +++++
 fs/proc/task_mmu.c                 | 19 +++++++++++++++----
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 5fa3f638848d..726951374c57 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -491,6 +491,7 @@ Memory Area, or VMA) there is a series of lines such as the following::
     FileCont512K:          0 kB
     FileCont1M:            0 kB
     FileCont2M:            0 kB
+    ContPTEMapped:         0 kB
     THPeligible:           0
     VmFlags: rd ex mr mw me dw
 
@@ -550,6 +551,10 @@ pmd size. Therefore the exact set of keys will vary by platform. It only
 includes pte-mapped memory and reports on anonymous and file-backed memory
 separately.
 
+"ContPTEMapped" is only present for architectures that support indicating a set
+of contiguously mapped ptes in their page tables. In this case, it indicates
+how much of the memory is currently mapped using contpte mappings.
+
 "THPeligible" indicates whether the mapping is eligible for allocating THP
 pages as well as the THP is PMD mappable or not - 1 if true, 0 otherwise.
 It just shows the current status.
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 29fee5b7b00b..0ebd6eb7efd4 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -465,6 +465,7 @@ struct mem_size_stats {
 	unsigned long anon_cont[CONT_ORDER_MAX + 1];
 	unsigned long file_cont[CONT_ORDER_MAX + 1];
 	struct cont_accumulator cacc;
+	unsigned long contpte_mapped;
 };
 
 static void cacc_init(struct mem_size_stats *mss)
@@ -548,7 +549,7 @@ static void smaps_page_accumulate(struct mem_size_stats *mss,
 
 static void smaps_account(struct mem_size_stats *mss, struct page *page,
 		bool compound, bool young, bool dirty, bool locked,
-		bool migration)
+		bool migration, bool contpte)
 {
 	int i, nr = compound ? compound_nr(page) : 1;
 	unsigned long size = nr * PAGE_SIZE;
@@ -572,6 +573,10 @@ static void smaps_account(struct mem_size_stats *mss, struct page *page,
 	if (!compound)
 		cacc_accumulate(mss, page);
 
+	/* Accumulate all the pages that are part of a contpte. */
+	if (contpte)
+		mss->contpte_mapped += size;
+
 	/*
 	 * Then accumulate quantities that may depend on sharing, or that may
 	 * differ page-by-page.
@@ -636,13 +641,16 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
 	struct vm_area_struct *vma = walk->vma;
 	bool locked = !!(vma->vm_flags & VM_LOCKED);
 	struct page *page = NULL;
-	bool migration = false, young = false, dirty = false;
+	bool migration = false, young = false, dirty = false, cont = false;
 	pte_t ptent = ptep_get(pte);
 
 	if (pte_present(ptent)) {
 		page = vm_normal_page(vma, addr, ptent);
 		young = pte_young(ptent);
 		dirty = pte_dirty(ptent);
+#ifdef pte_cont
+		cont = pte_cont(ptent);
+#endif
 	} else if (is_swap_pte(ptent)) {
 		swp_entry_t swpent = pte_to_swp_entry(ptent);
 
@@ -672,7 +680,7 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
 	if (!page)
 		return;
 
-	smaps_account(mss, page, false, young, dirty, locked, migration);
+	smaps_account(mss, page, false, young, dirty, locked, migration, cont);
 }
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
@@ -708,7 +716,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
 		mss->file_thp += HPAGE_PMD_SIZE;
 
 	smaps_account(mss, page, true, pmd_young(*pmd), pmd_dirty(*pmd),
-		      locked, migration);
+		      locked, migration, false);
 }
 #else
 static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
@@ -964,6 +972,9 @@ static void __show_smap(struct seq_file *m, const struct mem_size_stats *mss,
 					cont_label(i, label),
 					mss->file_cont[i] >> 10);
 	}
+#ifdef pte_cont
+	SEQ_PUT_DEC(" kB\nContPTEMapped:  ", mss->contpte_mapped);
+#endif
 	seq_puts(m, " kB\n");
 }
 
-- 
2.25.1


  parent reply	other threads:[~2023-06-13 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13 16:09 [PATCH v1 0/2] Report on physically contiguous memory in smaps Ryan Roberts
2023-06-13 16:09 ` [PATCH v1 1/2] mm: /proc/pid/smaps: Report large folio mappings Ryan Roberts
2023-06-13 16:09 ` Ryan Roberts [this message]
2023-06-13 18:44 ` [PATCH v1 0/2] Report on physically contiguous memory in smaps Yu Zhao
2023-06-14 10:41   ` Ryan Roberts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230613160950.3554675-3-ryan.roberts@arm.com \
    --to=ryan.roberts@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).