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

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

>>
>> But more importantly
>>
>> d) MMUPageSize is independent of the actual page mappings, and I don't
>>    think we should change these semantics.
> 
> That makes no sense. What is it good for then? Just a random number
> that looks good?

Especially after reading 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c I
ended up with he following conclusion:

"KernelPageSize" tells you in which granularity we can mmap()/munmap()
etc. Simple.

"MMUPageSize" tells us how this granularity is implemented (or emulated)
under the hood.

The case we care about is when MMUPageSize < KernelPageSize. A process
might have to know that detail even when nothing is currently/yet
faulted in.

Assume a process would perform an atomic that would cross MMUPageSize,
but not KernelPageSize. Depending on the architecture, atomics would not
work as expected in that case.

I'd expect other cases where an architecture might have to care about
the actual, smallest possible MMUPageSize it might be executed on while
running the program.

It's a shame we had to add MMUPageSize, but maybe it might resurface if
we ever support emulating 64K/16K user pagesizes on 4K MMUs.

> 
>>
>>
>> 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.
> 
> It doesn't seem like a good design. I don't know what that is good for.
> 
> What is reasonable to report something at least approximating what is
> really mapped.

I disagree. It is not of a lot of use to know "In this 1 TiB region,
there is something mapped with 2 MiB", and then exposing it under the
MMUPageSize umbrella with different (mapped) semantics.

AnonHugePages/ShmemPmdMapped/FilePmdMapped are better in that regard,
although historically suboptimal.

Ideally we'd have better statistics out of the box (similar to what
thpmaps does), but as we recently discussed in the context of "AnonZero"
we should much rather look into a better interface to expose something
like that (e.g., a new syscall where on can enable selected statistics),
including new tooling that can obtain exactly the statistics we want.

> 
>>
>> 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.
> 
> 
> Some magic other tool doesn't help with the current output confusing
> people.
Adding more confusion with this MMUPageSize extension is not an option.
We should likely clarify what MMUPageSize really means.

So my NAK stands.

CCing Lorenzo:
https://lore.kernel.org/all/20260225232708.87833-1-ak@linux.intel.com/


-- 
Cheers,

David