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

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

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

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

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

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

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

-Andi