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

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

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

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

> Adding more confusion with this MMUPageSize extension is not an option.
> We should likely clarify what MMUPageSize really means.

That would be an orthogonal documentation patch.


Thanks,
-Andi