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
