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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Mon, Mar 02, 2026 at 01:48:20PM -0800, Andi Kleen wrote:
> On Mon, Mar 02, 2026 at 10:05:23PM +0100, David Hildenbrand (Arm) wrote:
> > On 3/2/26 21:41, Andi Kleen wrote:
> > >> 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 thought most architectures don't support atomics crossing pages
> > > anyways. x86 supports it, but it's discouraged.
> >
> > Right. And if your user space thinks it has "64k" pages, when it's
> > actually emulated through "4k" pages under the hood, that could be a
> > problem: user space could perform an atomic "within" a 64k page that
>
> PPC user space doesn't do it.
>
> > 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
nearly-identically named entry that means something totally different (?!!)

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

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

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

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

Smaps is necessarily a user-facing contract at this point so we have to tread
carefully there.

>
> A new interface doesn't really change anything given that smaps
> is extensible.

See above.

>
> I'll look at the partial folio case, but will only handle
> it if it's simple.

Feel free to look at whatever you like, maintainers decide what gets
merged.

>
> > Ideally, that will tell you "how much" of a certain contiguous size is
> > mapped, if that contiguous size benefits somehow from TLB optimizations,
> > etc.
>
> The key word is "somehow". It's better to work with real use cases
> instead of such hypothetics.

Except your suggestion already demonstrates fundamental confusion about how
folios are mapped in userspace?

We have to live with the legacy of MMUPageSize it means what it
means. We're not adding variable-key entries to smaps full stop, because
they're ungreppable and confusing.

so in _real world_ terms we are looking at a new interface, not overloading
smaps.

>
> -Andi
>

Thanks, Lorenzo