Re: [PATCH v1] docs: filesystems: clarify KernelPageSize vs. MMUPageSize in smaps

["Lorenzo Stoakes (Oracle)" <ljs@kernel.org>]

On Thu, Mar 05, 2026 at 02:32:49PM +0100, David Hildenbrand (Arm) wrote:
>
> >
> > Ah wait you dedicate a whole paragraph after this to tha :)
>
> Correct :)
>
> >
> >> +mapping that is currently resident in RAM (RSS); the process's proportional
> >> +share of this mapping (PSS); and the number of clean and dirty shared and
> >> +private pages in the mapping.
> >> +
> >> +Historically, the "KernelPageSize" always corresponds to the "MMUPageSize",
> >> +except when a larger kernel page size is emulated on a system with a smaller
> >
> > NIT: is -> was, as historically implies past tense.
> >
> > But it's maybe better to say:
> >
> > +Historically, the "KernelPageSize" has always corresponded to the "MMUPageSize",
> >
> > And:
> >
> > +except when a larger kernel page size is being emulated on a system with a smaller
> >
>
> Given that the PPC64 thingy still exists in the tree, I'll probably do:
>
> "KernelPageSize" always corresponds to "MMUPageSize", except when a
> larger kernel page size is emulated on a system with a smaller page size
> used by the MMU, which is the case for some PPC64 setups with hugetlb.
>
> >> +page size used by the MMU, which was the case for PPC64 in the past.
> >> +Further, "KernelPageSize" and "MMUPageSize" always correspond to the
> >
> > NIT: Further -> Furthermore
> >
>
> Helpful.
>
> >> +smallest possible granularity (fallback) that could be encountered in a
> >
> > could be -> can be
> >
> > Since we are really talking about the current situation, even if this, is
> > effect, a legacy thing.
> >
> >> +VMA throughout its lifetime.  These values are not affected by any current
> >> +transparent grouping of pages by Linux (Transparent Huge Pages) or any
> >
> > 'transparent grouping of pages' reads a bit weirdly.
> >
> > Maybe simplify to:
> >
> > +These values are not affected by Transparent Huge Pages being in effect, or any...
>
> Works for me.
>
> >
> >> +current usage of larger MMU page sizes (either through architectural
> >
> > NIT: current usage -> usage
>
> Ack.
>
> >
> >> +huge-page mappings or other transparent groupings done by the MMU).
> >
> > Again I think 'transparent groupings' is a bit unclear. Perhaps instead:
> >
> > +huge-page mappings or other explicit or implicit coalescing of virtual ranges
> > +performed by the MMU).
>
> I'd assume the educated reader does not know what "explicit/implicit
> coalescing" even means, but works for me. :)
>
> >
> > ?
> >
> >> +"AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" provide insight into
> >> +the usage of some architectural huge-page mappings.
> >
> > Is 'some' necessary here? Seems to make it a bit vague.
>
> I had PUDs in mind. I can just call it
>
> "PMD-level architectural ..."
>
> >
> >>
> >>  The "proportional set size" (PSS) of a process is the count of pages it has
> >>  in memory, where each page is divided by the number of processes sharing it.
> >> @@ -528,10 +541,14 @@ pressure if the memory is clean. Please note that the printed value might
> >>  be lower than the real value due to optimizations used in the current
> >>  implementation. If this is not desirable please file a bug report.
> >>
> >> -"AnonHugePages" shows the amount of memory backed by transparent hugepage.
> >> +"AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" show the amount of
> >> +memory backed by transparent hugepages that are currently mapped through
> >> +architectural huge-page mappings (PMD). "AnonHugePages" corresponds to memory
> >
> > 'mapped through architectural huge-page mappings (PMD)' reads a bit strangely to
> > me,
> >
> > Perhaps 'mapped by transparent huge pages at a PMD page table level' instead?
> >
>
> I'll simplify to
>
> "mapped by architectural huge-page mappings at the PMD level"
>
>
> >> +that does not belong to a file, "ShmemPmdMapped" to shared memory (shmem/tmpfs)
> >> +and "FilePmdMapped" to file-backed memory (excluding shmem/tmpfs).
> >>
> >> -"ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by
> >> -huge pages.
> >> +There are no dedicated entries for transparent huge pages (or similar concepts)
> >> +that are not mapped through architectural huge-page mappings (PMD).
> >
> > similarly, perhaps better as 'are not mapped by transparent huge pages at a PMD
> > page table level'?
>
> I'll similarly call it "mapped by architectural huge-page mappings at
> the PMD level"
>
> Thanks a bunch!
>
> --
> Cheers,
>
> David

Thanks on all!