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

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

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
actually crosses two 4k pages. So it must be aware that mmap etc operate
in 64k, but the underlying emulation might be smaller.

I suspect (but don't know for sure) that ppc exposed it for such a
reason (maybe not atomic, but something else where user space might be
able to detect the difference).

It's not that common nowadays, but I suspect it might get more common in
the future again.

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

Instead, if we want better statistics (and I think we want) regarding
how things are mapped, we should look into a better interface.

Ideally, that will tell you "how much" of a certain contiguous size is
mapped, if that contiguous size benefits somehow from TLB optimizations,
etc.

Similar to tlbmaps but easier to consume (and obtain, IIRC thpmaps
requires root permissions and has to jump through some racy hoops to
detect folio sizes) and easier to configure and extend.

-- 
Cheers,

David