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 0/2] Report on physically contiguous memory in smaps
Date: Tue, 13 Jun 2023 17:09:48 +0100 [thread overview]
Message-ID: <20230613160950.3554675-1-ryan.roberts@arm.com> (raw)
Hi All,
I thought I would try my luck with this pair of patches...
This series adds new entries to /proc/pid/smaps[_rollup] to report on physically
contiguous runs of memory. The first patch reports on the sizes of the runs by
binning into power-of-2 blocks and reporting how much memory is in which bin.
The second patch reports on how much of the memory is contpte-mapped in the page
table (this is a hint that arm64 supports to tell the HW that a range of ptes
map physically contiguous memory).
With filesystems now supporting large folios in the page cache, this provides a
useful way to see what sizes are actually getting mapped. And with the prospect
of large folios for anonymous memory and contpte mapping for conformant large
folios on the horizon, this reporting will become useful to aid application
performance optimization.
Perhaps I should really be submitting these patches as part of my large anon
folios and contpte sets (which I plan to post soon), but given this touches
the user ABI, I thought it was sensible to post it early and separately to get
feedback.
It would specifically be good to get feedback on:
- The exact set of new fields depend on the system that its being run on. Does
this cause problem for compat? (specifically the bins are determined based
on PAGE_SIZE and PMD_SIZE).
- The ContPTEMapped field is effectively arm64-specific. What is the preferred
way to handle arch-specific values if not here?
The patches are based on mm-unstable (dd69ce3382a2). Some minor conflicts will
need to be resolved if rebasing to Linus's tree. I have a branch at [1]. I've
tested on Ampere Altra (arm64) only.
[1] https://gitlab.arm.com/linux-arm/linux-rr/-/tree/features/granule_perf/folio_smap-lkml_v1
Thanks,
Ryan
Ryan Roberts (2):
mm: /proc/pid/smaps: Report large folio mappings
mm: /proc/pid/smaps: Report contpte mappings
Documentation/filesystems/proc.rst | 31 +++++++
fs/proc/task_mmu.c | 134 ++++++++++++++++++++++++++++-
2 files changed, 161 insertions(+), 4 deletions(-)
--
2.25.1
next 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 Ryan Roberts [this message]
2023-06-13 16:09 ` [PATCH v1 1/2] mm: /proc/pid/smaps: Report large folio mappings Ryan Roberts
2023-06-13 16:09 ` [PATCH v1 2/2] mm: /proc/pid/smaps: Report contpte mappings Ryan Roberts
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-1-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).