Re: [PATCH v2] smaps: Report correct page sizes with THP

["David Hildenbrand (Arm)" <david@kernel.org>]

On 2/26/26 00:27, Andi Kleen wrote:
> The earlier version of this patch kit wasn't that well received,
> with the main objection being non support for mTHP. This variant
> tracks any mTHP sizes in a VMA and reports them with MMUPageSizeN in smaps,
> with increasing N.  The base page size is still reported w/o a
> number postfix to stay compatible.
> 
> The nice thing is that the patch is actually simpler and more
> straight forward than the THP only variant. Also improved the
> documentation.
> 
> Recently I wasted quite some time debugging why THP didn't work, when it
> was just smaps always reporting the base page size. It has separate
> counts for (non m) THP, but using them is not always obvious.
> I left KernelPageSize alone.
> 
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---

You should CC people that were commented on earlier versions.

I still don't like this.


a) Just because a folio has a certain order does not imply that hw actually
coalesces anything. MMUPageSize is otherwise misleading.

b) Simply because you find a folio of a certain order does not imply that
it is even fully mapped in there.

c) PTE coalescing on AMD can even span folios

But more importantly

d) MMUPageSize is independent of the actual page mappings, and I don't
   think we should change these semantics.


Let's see why MMUPageSize was added in the first place:

commit 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c
Author: Mel Gorman <mel@csn.ul.ie>
Date:   Tue Jan 6 14:38:54 2009 -0800

    mm: report the MMU pagesize in /proc/pid/smaps
    
    The KernelPageSize entry in /proc/pid/smaps is the pagesize used by the
    kernel to back a VMA.  This matches the size used by the MMU in the
    majority of cases.  However, one counter-example occurs on PPC64 kernels
    whereby a kernel using 64K as a base pagesize may still use 4K pages for
    the MMU on older processor.  To distinguish, this patch reports
    MMUPageSize as the pagesize used by the MMU in /proc/pid/smaps.


So instead of 64K (PAGE_SIZE), they reported 4K. Always. Even if nothing is mapped.

So you could indicate all MMUPageSize that hardware possibly supports in here.
I don't think it's that helpful.

We once discussed exporting more stats here (similar to AnonHugePages/ShmemPmdMapped, ...)
but we were concerned about creating a mess with mTHP stats.

For this reason, Ryan developed a tool (tools/mm/thpmaps) to introspect the
actual mappings.

See

commit 2444172cfde45a3d6e655f50c620727c76bab4a2
Author: Ryan Roberts <ryan.roberts@arm.com>
Date:   Tue Jan 16 14:12:35 2024 +0000

    tools/mm: add thpmaps script to dump THP usage info
    
    With the proliferation of large folios for file-backed memory, and more
    recently the introduction of multi-size THP for anonymous memory, it is
    becoming useful to be able to see exactly how large folios are mapped into
    processes.  For some architectures (e.g.  arm64), if most memory is mapped
    using contpte-sized and -aligned blocks, TLB usage can be optimized so
    it's useful to see where these requirements are and are not being met.


-- 
Cheers,

David