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

[Andi Kleen <ak@linux.intel.com>]

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

That's true. However reporting 4K for a 2MB THP mapping today is even
more misleading.  That's where I started, it misled me totally!

So you're asking for an architecture specific / cpu specific hook to filter it?
I suppose it could be added, however it might take a very long time
to get merged, and even that cannot handle all corner cases.

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

Ok. I suppose the walker could handle that.

> 
> c) PTE coalescing on AMD can even span folios

and d) it might randomly not happen due to various runtime reasons.

It seems the only thing that would satisfy all your correctness 
criteria would be to not report a MMUPageSize at all, but we cannot do that
for compatibility reasons as you yourself pointed out.

Given that your requirements are impossible, we have to settle on
something better. I still think that what I proposed is a good
compromise, although yes it's far from perfect.

> 
> 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?

> 
> 
> 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.

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

Right.

> 
> 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.

Yes I can always dump the page tables through debugfs (or at least I could
if not most distributions don't bother to enable that config option
for unknown reasons)


-Andi