docs: filesystems: clarify KernelPageSize vs. MMUPageSize in smaps
Subsystems (4)
PATCH 1/1 docs: filesystems: clarify KernelPageSize vs. MMUPageSize in smaps
There was recently some confusion around THPs and the interaction with KernelPageSize / MMUPageSize. Historically, these entries always correspond to the smallest size we could encounter, not any current usage of transparent huge pages or larger sizes used by the MMU.
Ever since we added THP support many, many years ago, these entries would keep reporting the smallest (fallback) granularity in a VMA.
For this reason, they default to PAGE_SIZE for all VMAs except for VMAs where we have the guarantee that the system and the MMU will always use larger page sizes. hugetlb, for example, exposes a custom vm_ops->pagesize callback to handle that. Similarly, dax/device exposes a custom vm_ops->pagesize callback and provides similar guarantees.
Let's clarify the historical meaning of KernelPageSize / MMUPageSize, and point at "AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" regarding PMD entries.
While at it, document "FilePmdMapped", clarify what the "AnonHugePages" and "ShmemPmdMapped" entries really mean, and make it clear that there are no other entries for other THP/folio sizes or mappings.
--- Documentation/filesystems/proc.rst | 37 ++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 10 deletions(-)
Documentation/filesystems/proc.rst +27 -10
@@ -464,6 +464,7 @@ Memory Area, or VMA) there is a series of lines such as the following:: KSM: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB + FilePmdMapped: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB
@@ -477,13 +478,25 @@ Memory Area, or VMA) there is a series of lines such as the following:: The first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. Following lines show the size of the -mapping (size); the size of each page allocated when backing a VMA -(KernelPageSize), which is usually the same as the size in the page table -entries; the page size used by the MMU when backing a VMA (in most cases, -the same as KernelPageSize); the amount of the 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. +mapping (size); the smallest possible page size allocated when +backing a VMA (KernelPageSize), which is the granularity in which VMA +modifications can be performed; the smallest possible page size that could +be used by the MMU (MMUPageSize) when backing a VMA; the amount of the +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 +page size used by the MMU, which was the case for PPC64 in the past. +Further, "KernelPageSize" and "MMUPageSize" always correspond to the +smallest possible granularity (fallback) that could be encountered in a +VMA throughout its lifetime. These values are not affected by any current +transparent grouping of pages by Linux (Transparent Huge Pages) or any +current usage of larger MMU page sizes (either through architectural +huge-page mappings or other transparent groupings done by the MMU). +"AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" provide insight into +the usage of some architectural huge-page mappings. 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 +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). "Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical
Signature · 1 line
2.43.0
Quoted 39 lines · David Hildenbrand (Arm)
There was recently some confusion around THPs and the interaction with KernelPageSize / MMUPageSize. Historically, these entries always correspond to the smallest size we could encounter, not any current usage of transparent huge pages or larger sizes used by the MMU.
Ever since we added THP support many, many years ago, these entries would keep reporting the smallest (fallback) granularity in a VMA.
For this reason, they default to
PAGE_SIZEfor all VMAs except for VMAs where we have the guarantee that the system and the MMU will always use larger page sizes. hugetlb, for example, exposes a customvm_ops->pagesizecallback to handle that. Similarly, dax/device exposes a customvm_ops->pagesizecallback and provides similar guarantees.Let's clarify the historical meaning of KernelPageSize / MMUPageSize, and point at "AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" regarding PMD entries.
While at it, document "FilePmdMapped", clarify what the "AnonHugePages" and "ShmemPmdMapped" entries really mean, and make it clear that there are no other entries for other THP/folio sizes or mappings.
Cc Andrew Morton <[email protected]>Cc Lorenzo Stoakes <[email protected]>Cc Zi Yan <[email protected]>Cc Baolin Wang <[email protected]>Cc Liam R. Howlett <[email protected]>Cc Nico Pache <[email protected]>Cc Ryan Roberts <[email protected]Cc Dev Jain <[email protected]>Cc Barry Song <[email protected]>Cc Lance Yang <[email protected]>Cc Jonathan Corbet <[email protected]>Cc Shuah Khan <[email protected]>Cc Usama Arif <[email protected]>Cc Andi Kleen <[email protected]>Signed-off-by David Hildenbrand (Arm) <[email protected]>
Quoted 4 lines
--- Documentation/filesystems/proc.rst | 37 ++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 10 deletions(-)
LGTM.
Best Regards,
Yan, Zi
Quoted 4 lines · David Hildenbrand (Arm)
There was recently some confusion around THPs and the interaction with KernelPageSize / MMUPageSize. Historically, these entries always correspond to the smallest size we could encounter, not any current usage of transparent huge pages or larger sizes used by the MMU.
It still seems like a bug to me, only documented now, but seems I'm in the minority on that.
But anyways if you change this file you should probably remove the duplicated KernelPageSize/MMUPageSize entries in the example too. That triped me up the last time.
-Andi
Quoted 8 lines · Andi Kleen
Quoted 4 lines · David Hildenbrand (Arm)
There was recently some confusion around THPs and the interaction with KernelPageSize / MMUPageSize. Historically, these entries always correspond to the smallest size we could encounter, not any current usage of transparent huge pages or larger sizes used by the MMU.
It still seems like a bug to me, only documented now, but seems I'm in the minority on that.
I'd agree that something smarter and more future proof should have been done if THPs wouldn't have been added (checks notes) 15 years ago and how KernelPageSize / MMUPageSize behaves and what it means would already be set in stone for a long time.
People decided to add things like "AnonHugePages" (which I also detest, but here we are) instead.
I wish we would have never exposed MMUPageSize (in 2009) to handle some ppc oddity.
While digging through some history, there were earlier conclusions (around 10 years ago) that MMUPageSize [1] is not a good fit, and people even tried exposing actual amounts (Ptes@4kB, Ptes@2MB). I don't think that's the right approach either for various reasons raised already (e.g., doesn't really tell you the full TLB/MMU story).
Quoted 4 lines
But anyways if you change this file you should probably remove the duplicated KernelPageSize/MMUPageSize entries in the example too. That triped me up the last time.
Good point. I also discovered that that PPC64 thing is still in place (maybe it's dead code, but at least code-wise, it's not a thing from the past ).
[1] https://lkml.org/lkml/2016/11/29/882
Signature · 3 lines
Cheers, David
Quoted 39 lines · David Hildenbrand (Arm)
There was recently some confusion around THPs and the interaction with KernelPageSize / MMUPageSize. Historically, these entries always correspond to the smallest size we could encounter, not any current usage of transparent huge pages or larger sizes used by the MMU.
Ever since we added THP support many, many years ago, these entries would keep reporting the smallest (fallback) granularity in a VMA.
For this reason, they default to
PAGE_SIZEfor all VMAs except for VMAs where we have the guarantee that the system and the MMU will always use larger page sizes. hugetlb, for example, exposes a customvm_ops->pagesizecallback to handle that. Similarly, dax/device exposes a customvm_ops->pagesizecallback and provides similar guarantees.Let's clarify the historical meaning of KernelPageSize / MMUPageSize, and point at "AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" regarding PMD entries.
While at it, document "FilePmdMapped", clarify what the "AnonHugePages" and "ShmemPmdMapped" entries really mean, and make it clear that there are no other entries for other THP/folio sizes or mappings.
Cc Andrew Morton <[email protected]>Cc Lorenzo Stoakes <[email protected]>Cc Zi Yan <[email protected]>Cc Baolin Wang <[email protected]>Cc Liam R. Howlett <[email protected]>Cc Nico Pache <[email protected]>Cc Ryan Roberts <[email protected]Cc Dev Jain <[email protected]>Cc Barry Song <[email protected]>Cc Lance Yang <[email protected]>Cc Jonathan Corbet <[email protected]>Cc Shuah Khan <[email protected]>Cc Usama Arif <[email protected]>Cc Andi Kleen <[email protected]>Signed-off-by David Hildenbrand (Arm) <[email protected]>
Quoted 1 line
---
Makes sense to me. Feel free to add:
Quoted 23 lines · David Hildenbrand (Arm)
There was recently some confusion around THPs and the interaction with KernelPageSize / MMUPageSize. Historically, these entries always correspond to the smallest size we could encounter, not any current usage of transparent huge pages or larger sizes used by the MMU.
Ever since we added THP support many, many years ago, these entries would keep reporting the smallest (fallback) granularity in a VMA.
For this reason, they default to
PAGE_SIZEfor all VMAs except for VMAs where we have the guarantee that the system and the MMU will always use larger page sizes. hugetlb, for example, exposes a customvm_ops->pagesizecallback to handle that. Similarly, dax/device exposes a customvm_ops->pagesizecallback and provides similar guarantees.Let's clarify the historical meaning of KernelPageSize / MMUPageSize, and point at "AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" regarding PMD entries.
While at it, document "FilePmdMapped", clarify what the "AnonHugePages" and "ShmemPmdMapped" entries really mean, and make it clear that there are no other entries for other THP/folio sizes or mappings.
Quoted 16 lines
Cc Andrew Morton <[email protected]>Cc Lorenzo Stoakes <[email protected]>Cc Zi Yan <[email protected]>Cc Baolin Wang <[email protected]>Cc Liam R. Howlett <[email protected]>Cc Nico Pache <[email protected]>Cc Ryan Roberts <[email protected]Cc Dev Jain <[email protected]>Cc Barry Song <[email protected]>Cc Lance Yang <[email protected]>Cc Jonathan Corbet <[email protected]>Cc Shuah Khan <[email protected]>Cc Usama Arif <[email protected]>Cc Andi Kleen <[email protected]>Signed-off-by David Hildenbrand (Arm) <[email protected]>
Thanks.
Quoted 23 lines · David Hildenbrand (Arm)
There was recently some confusion around THPs and the interaction with KernelPageSize / MMUPageSize. Historically, these entries always correspond to the smallest size we could encounter, not any current usage of transparent huge pages or larger sizes used by the MMU.
Ever since we added THP support many, many years ago, these entries would keep reporting the smallest (fallback) granularity in a VMA.
For this reason, they default to
PAGE_SIZEfor all VMAs except for VMAs where we have the guarantee that the system and the MMU will always use larger page sizes. hugetlb, for example, exposes a customvm_ops->pagesizecallback to handle that. Similarly, dax/device exposes a customvm_ops->pagesizecallback and provides similar guarantees.Let's clarify the historical meaning of KernelPageSize / MMUPageSize, and point at "AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" regarding PMD entries.
While at it, document "FilePmdMapped", clarify what the "AnonHugePages" and "ShmemPmdMapped" entries really mean, and make it clear that there are no other entries for other THP/folio sizes or mappings.
Quoted 16 lines
Cc Andrew Morton <[email protected]>Cc Lorenzo Stoakes <[email protected]>Cc Zi Yan <[email protected]>Cc Baolin Wang <[email protected]>Cc Liam R. Howlett <[email protected]>Cc Nico Pache <[email protected]>Cc Ryan Roberts <[email protected]Cc Dev Jain <[email protected]>Cc Barry Song <[email protected]>Cc Lance Yang <[email protected]>Cc Jonathan Corbet <[email protected]>Cc Shuah Khan <[email protected]>Cc Usama Arif <[email protected]>Cc Andi Kleen <[email protected]>Signed-off-by David Hildenbrand (Arm) <[email protected]>
Overall this is great, some various nits and comments below so we can tweak it.
Cheers, Lorenzo
Quoted 21 lines
--- Documentation/filesystems/proc.rst | 37 ++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 10 deletions(-)Documentation/filesystems/proc.rst +1
-1@@ -464,6 +464,7 @@ Memory Area, or VMA) there is a series of lines such as the following:: KSM: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB + FilePmdMapped: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB@@ -477,13 +478,25 @@ Memory Area, or VMA) there is a series of lines such as the following:: The first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. Following lines show the size of the -mapping (size); the size of each page allocated when backing a VMA
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 484
Quoted 10 lines
Documentation/filesystems/proc.rst +4
-6-(KernelPageSize), which is usually the same as the size in the page table -entries; the page size used by the MMU when backing a VMA (in most cases, -the same as KernelPageSize); the amount of the 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. +mapping (size); the smallest possible page size allocated when +backing a VMA (KernelPageSize), which is the granularity in which VMA +modifications can be performed; the smallest possible page size that could +be used by the MMU (MMUPageSize) when backing a VMA; the amount of the
Is it worth retaining 'in most cases the same as KernelPageSize' here?
Ah wait you dedicate a whole paragraph after this to tha :)
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 490
Quoted 6 lines
Documentation/filesystems/proc.rst +6
-0+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
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 492
Quoted 2 lines
Documentation/filesystems/proc.rst +2
-0+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
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 493
Quoted 1 line
Documentation/filesystems/proc.rst +1
-0+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.
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 495
Quoted 2 lines
Documentation/filesystems/proc.rst +2
-0+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...
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 496
Quoted 1 line
Documentation/filesystems/proc.rst +1
-0+current usage of larger MMU page sizes (either through architectural
NIT: current usage -> usage
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 497
Quoted 1 line
Documentation/filesystems/proc.rst +1
-0+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).
?
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 499
Quoted 2 lines
Documentation/filesystems/proc.rst +2
-0+"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.
Documentation/filesystems/proc.rst pressure if the memory is clean. Please note that the printed value might · line 546
Quoted 11 lines
Documentation/filesystems/proc.rst +3
-1The "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?
Documentation/filesystems/proc.rst pressure if the memory is clean. Please note that the printed value might · line 551
Quoted 7 lines
Documentation/filesystems/proc.rst +4
-2+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'?
Quoted 6 lines
Documentation/filesystems/proc.rst +0
-1"Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical --2.43.0
Quoted 3 lines
Ah wait you dedicate a whole paragraph after this to tha :)
Correct :)
Quoted 10 lines
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 490
Quoted 7 lines
Documentation/filesystems/proc.rst +6
-0+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 smallerNIT: is -> was, as historically implies past tense.
Quoted 8 lines
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.
Quoted 5 lines
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 492
Quoted 2 lines
Documentation/filesystems/proc.rst +2
-0+page size used by the MMU, which was the case for PPC64 in the past. +Further, "KernelPageSize" and "MMUPageSize" always correspond to theNIT: Further -> Furthermore
Helpful.
Quoted 7 lines
Quoted 1 line
+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.
Quoted 8 lines
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 495
Quoted 2 lines
Documentation/filesystems/proc.rst +2
-0+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.
Quoted 4 lines
Quoted 2 lines
+current usage of larger MMU page sizes (either through architectural
NIT: current usage -> usage
Ack.
Review
Quoted 7 lines
Quoted 2 lines
+huge-page mappings or other transparent groupings done by the MMU).
Again I think 'transparent groupings' is a bit unclear. Perhaps instead:
(quoted diff) +2
-0+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. :)
Quoted 7 lines
?
Quoted 2 lines
+"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 ..."
Quoted 16 lines
Documentation/filesystems/proc.rst pressure if the memory is clean. Please note that the printed value might · line 546
Quoted 12 lines
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.
Documentation/filesystems/proc.rst +3
-1@@ -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,
Quoted 2 lines
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"
Quoted 10 lines
Documentation/filesystems/proc.rst pressure if the memory is clean. Please note that the printed value might · line 551
Quoted 7 lines
Documentation/filesystems/proc.rst +4
-2+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!
Signature · 3 lines
Cheers, David
Quoted 125 lines · David Hildenbrand (Arm)
Quoted 3 lines
Ah wait you dedicate a whole paragraph after this to tha :)
Correct :)
Quoted 10 lines
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 490
Quoted 7 lines
Documentation/filesystems/proc.rst +6
-0+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 smallerNIT: is -> was, as historically implies past tense.
Quoted 8 lines
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.
Quoted 5 lines
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 492
Quoted 2 lines
Documentation/filesystems/proc.rst +2
-0+page size used by the MMU, which was the case for PPC64 in the past. +Further, "KernelPageSize" and "MMUPageSize" always correspond to theNIT: Further -> Furthermore
Helpful.
Quoted 7 lines
Quoted 1 line
+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.
Quoted 8 lines
Documentation/filesystems/proc.rst Memory Area, or VMA) there is a series of lines such as the following:: · line 495
Quoted 2 lines
Documentation/filesystems/proc.rst +2
-0+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.
Quoted 4 lines
Quoted 2 lines
+current usage of larger MMU page sizes (either through architectural
NIT: current usage -> usage
Ack.
Review
Quoted 7 lines
Quoted 2 lines
+huge-page mappings or other transparent groupings done by the MMU).
Again I think 'transparent groupings' is a bit unclear. Perhaps instead:
(quoted diff) +2
-0+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. :)
Quoted 7 lines
?
Quoted 2 lines
+"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 ..."
Quoted 16 lines
Documentation/filesystems/proc.rst pressure if the memory is clean. Please note that the printed value might · line 546
Quoted 12 lines
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.
Documentation/filesystems/proc.rst +3
-1@@ -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,
Quoted 2 lines
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"
Quoted 10 lines
Documentation/filesystems/proc.rst pressure if the memory is clean. Please note that the printed value might · line 551
Quoted 7 lines
Documentation/filesystems/proc.rst +4
-2+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"
Quoted 6 lines
Thanks a bunch!
--
Cheers,David
Thanks on all!