Re: [PATCH v3 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/05/2015 03:21 PM, Konstantin Khlebnikov wrote:
On 05.08.2015 16:01, Vlastimil Babka wrote:
From: Jerome Marchand <jmarchan@xxxxxxxxxx>

It's currently inconvenient to retrieve MM_ANONPAGES value from status
and statm files and there is no way to separate MM_FILEPAGES and
MM_SHMEMPAGES. Add VmAnon, VmFile and VmShm lines in /proc/<pid>/status
to solve these issues.

Signed-off-by: Jerome Marchand <jmarchan@xxxxxxxxxx>
Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx>
---
   Documentation/filesystems/proc.txt | 10 +++++++++-
   fs/proc/task_mmu.c                 | 13 +++++++++++--
   2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index fcf67c7..fadd1b3 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -168,6 +168,9 @@ For example, to get the status information of a process, all you have to do is
     VmLck:         0 kB
     VmHWM:       476 kB
     VmRSS:       476 kB
+  VmAnon:      352 kB
+  VmFile:      120 kB
+  VmShm:         4 kB
     VmData:      156 kB
     VmStk:        88 kB
     VmExe:        68 kB
@@ -229,7 +232,12 @@ Table 1-2: Contents of the status files (as of 4.1)
    VmSize                      total program size
    VmLck                       locked memory size
    VmHWM                       peak resident set size ("high water mark")
- VmRSS                       size of memory portions
+ VmRSS                       size of memory portions. It contains the three
+                             following parts (VmRSS = VmAnon + VmFile + VmShm)
+ VmAnon                      size of resident anonymous memory
+ VmFile                      size of resident file mappings
+ VmShm                       size of resident shmem memory (includes SysV shm,
+                             mapping of tmpfs and shared anonymous mappings)

"Vm" is an acronym for Virtual Memory, but all these are not virtual.
They are real pages. Let's leave VmRSS as is and invent better prefix
for new fields: something like "Mem", "Pg", or no prefix at all.

No prefix would be IMHO confusing. Mem could work, but it's not exactly consistent with the rest. I think only VmPeak and VmSize talk about virtual memory. The rest of existing counters is about physical memory being mapped into that virtual memory or consumed by supporting it (PTE, PMD) or swapped out. I don't see any difference for the new counters here, they would just stand out oddly with some new prefix IMHO.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]