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

[David Hildenbrand (Arm)]

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