linux-kernel - [PATCH v1 0/2] Report on physically contiguous memory in smaps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Jun 2023 17:09:48 +0100
From:   Ryan Roberts <ryan.roberts@....com>
To:     Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Yu Zhao <yuzhao@...gle.com>
Cc:     Ryan Roberts <ryan.roberts@....com>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: [PATCH v1 0/2] Report on physically contiguous memory in smaps

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