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

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

On Tue, Mar 03, 2026 at 09:39:14AM +0000, Lorenzo Stoakes wrote:
> > > actually crosses two 4k pages. So it must be aware that mmap etc operate
> > > in 64k, but the underlying emulation might be smaller.
> >
> > Sounds like a very contrived use case, which I'm not sure actually
> > happens.  From my past experiences most software usually doesn't use
> > complicated enumerations anyways but just hard codes something
> > reasonable (like in your example just always assume 4K worst case).
> > From their POV it makes sense, how would you test
> > a complicated enumeration for cases that don't happen on your
> > current system.
> 
> I'm sorry but it's a legacy user-facing stat, we don't get to change it or add a

I would rather call it a legacy user-facing lie at this point.

Labelling something with 4K that is only 2MB is just wrong and
incorrect. 

> > > >> 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.
> > > >
> > > > That's fine, they can use the min, or just the first match
> > > > (which is always the smallest)
> > > >
> > > >>
> > > >> 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.
> > > >
> > > > Okay, so if I follow that correctly you're suggesting
> > > > to change KernelPageSize, not MMUPageSize. I can do that change.
> > >
> > > Not at all. I'm saying that we leave KernelPageSize and MMUPageSize
> > > alone, just as they are today.
> >
> > That doesn't solve the problem that motivated my patch
> > smaps is confusing today and would stay so.
> 
> Except as you've been told you can find this information out in different
> ways.

Yes I figured this out by myself, but only wasting a lot of time caused
by the confusing and incorrect legacy interface. That's the problem
I'm trying to address here.

Thank you for rubbing salt into the wounds.

The crazy thing about this is that hugetlbfs even does it correctly,
it's only THP that is blatantly wrong.

> 
> >
> > >
> > > Instead, if we want better statistics (and I think we want) regarding
> > > how things are mapped, we should look into a better interface.
> >
> > I don't see how a new interface helps really. Some of the problems
> 
> I mean, you want information X, we're suggesting the providing of an interface
> to provide information X and... you don't see how that helps?

My goal was to fix the old interface to not blatantly report wrong
information. A new magical interface doesn't really help with that.


> 
> > you mentioned earlier could be either solved today with smaps
> > (e.g. handling the case when a folio is mapped partially and just
> > report the smaller page size), or are unsolveable in the general case
> > (what the TLB actually handles)
> 
> We're not having multiple entries in smaps for every mapping size, it's broken
> and ungreppable, and very liable to add additional confusion to users.

Okay, I guess one way to address your objections with "ungreppable" 
would be to report the majority page size in MMUPageSize and call
the minority page sizes something else that doesn't trigger on grep.

(MMUSecondaryPS or something like that)

If you don't like numbers I guess we can spell it out.


> A new interface gives us flexibility to do what we want, we aren't running out
> of syscalls or places to put statistics.

I don't see why a new interface is needed TBH. Can just add fields
and fix the existing fields not to lie. Yes need to take care of 
compatibility, I don't disagree on that. But just adding new interfaces
for everything instead of maintaining the old stuff properly isn't
the right answer.


-Andi