Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1238222 > unrolled thread
| Started by | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| First post | 2015-10-02 15:40 +0200 |
| Last post | 2015-10-05 07:00 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH v4 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status Vlastimil Babka <vbabka@suse.cz> - 2015-10-02 15:40 +0200
Re: [PATCH v4 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status Andrew Morton <akpm@linux-foundation.org> - 2015-10-03 00:50 +0200
Re: [PATCH v4 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status Hugh Dickins <hughd@google.com> - 2015-10-05 07:00 +0200
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2015-10-02 15:40 +0200 |
| Subject | [PATCH v4 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status |
| Message-ID | <qf8J4-4MS-37@gated-at.bofh.it> |
From: Jerome Marchand <jmarchan@redhat.com>
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 RssAnon, RssFile and RssShm lines in /proc/<pid>/status
to solve these issues.
Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Acked-by: Michal Hocko <mhocko@suse.com>
---
Documentation/filesystems/proc.txt | 10 +++++++++-
fs/proc/task_mmu.c | 14 ++++++++++++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 82d3657..c887a42 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -169,6 +169,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
+ RssAnon 352 kB
+ RssFile: 120 kB
+ RssShm: 4 kB
VmData: 156 kB
VmStk: 88 kB
VmExe: 68 kB
@@ -231,7 +234,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 = RssAnon + RssFile + RssShm)
+ RssAnon size of resident anonymous memory
+ RssFile size of resident file mappings
+ RssShm size of resident shmem memory (includes SysV shm,
+ mapping of tmpfs and shared anonymous mappings)
VmData size of data, stack, and text segments
VmStk size of data, stack, and text segments
VmExe size of text segment
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 9b9708e..7332afd 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -23,9 +23,13 @@
void task_mem(struct seq_file *m, struct mm_struct *mm)
{
- unsigned long data, text, lib, swap, ptes, pmds;
+ unsigned long data, text, lib, swap, ptes, pmds, anon, file, shmem;
unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss;
+ anon = get_mm_counter(mm, MM_ANONPAGES);
+ file = get_mm_counter(mm, MM_FILEPAGES);
+ shmem = get_mm_counter(mm, MM_SHMEMPAGES);
+
/*
* Note: to minimize their overhead, mm maintains hiwater_vm and
* hiwater_rss only when about to *lower* total_vm or rss. Any
@@ -36,7 +40,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
hiwater_vm = total_vm = mm->total_vm;
if (hiwater_vm < mm->hiwater_vm)
hiwater_vm = mm->hiwater_vm;
- hiwater_rss = total_rss = get_mm_rss(mm);
+ hiwater_rss = total_rss = anon + file + shmem;
if (hiwater_rss < mm->hiwater_rss)
hiwater_rss = mm->hiwater_rss;
@@ -53,6 +57,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
"VmPin:\t%8lu kB\n"
"VmHWM:\t%8lu kB\n"
"VmRSS:\t%8lu kB\n"
+ "RssAnon:\t%8lu kB\n"
+ "RssFile:\t%8lu kB\n"
+ "RssShm:\t%8lu kB\n"
"VmData:\t%8lu kB\n"
"VmStk:\t%8lu kB\n"
"VmExe:\t%8lu kB\n"
@@ -66,6 +73,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
mm->pinned_vm << (PAGE_SHIFT-10),
hiwater_rss << (PAGE_SHIFT-10),
total_rss << (PAGE_SHIFT-10),
+ anon << (PAGE_SHIFT-10),
+ file << (PAGE_SHIFT-10),
+ shmem << (PAGE_SHIFT-10),
data << (PAGE_SHIFT-10),
mm->stack_vm << (PAGE_SHIFT-10), text, lib,
ptes >> 10,
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Andrew Morton <akpm@linux-foundation.org> |
|---|---|
| Date | 2015-10-03 00:50 +0200 |
| Subject | Re: [PATCH v4 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status |
| Message-ID | <qfhjj-de-7@gated-at.bofh.it> |
| In reply to | #1238222 |
On Fri, 2 Oct 2015 15:35:51 +0200 Vlastimil Babka <vbabka@suse.cz> wrote: > From: Jerome Marchand <jmarchan@redhat.com> > > 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 RssAnon, RssFile and RssShm lines in /proc/<pid>/status > to solve these issues. This changelog is also head-spinning. Why is it talking about MM_ANONPAGES and MM_FILEPAGES in the context of procfs files? Those terms are kernel-internal stuff and are meaningless to end users. So can we please start over with the changelogs? - What is wrong with the current user interface? - What changes are we proposing making? - What new fields are added to the UI? What is their meaning to users? - Are any existing UI fields altered? If so how and why and what impact will that have? Extra points will be awarded for example procfs output. This is the important stuff! Once this is all clearly described, understood and reviewed, then we can get into the kernel-internal-microdetails like MM_ANONPAGES. (And "What is wrong with the current user interface?" is important. What value does this patchset provide to end users? Why does anyone even want these changes?) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Hugh Dickins <hughd@google.com> |
|---|---|
| Date | 2015-10-05 07:00 +0200 |
| Subject | Re: [PATCH v4 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status |
| Message-ID | <qg62t-5sI-5@gated-at.bofh.it> |
| In reply to | #1238222 |
On Fri, 2 Oct 2015, Vlastimil Babka wrote:
> From: Jerome Marchand <jmarchan@redhat.com>
>
> 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 RssAnon, RssFile and RssShm lines in /proc/<pid>/status
> to solve these issues.
>
> Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Acked-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Acked-by: Michal Hocko <mhocko@suse.com>
Mostly
Acked-by: Hugh Dickins <hughd@google.com>
but I loathe the alignment...
> ---
> Documentation/filesystems/proc.txt | 10 +++++++++-
> fs/proc/task_mmu.c | 14 ++++++++++++--
> 2 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index 82d3657..c887a42 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -169,6 +169,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
> + RssAnon 352 kB
> + RssFile: 120 kB
> + RssShm: 4 kB
That looks nice...
> VmData: 156 kB
> VmStk: 88 kB
> VmExe: 68 kB
> @@ -231,7 +234,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 = RssAnon + RssFile + RssShm)
> + RssAnon size of resident anonymous memory
> + RssFile size of resident file mappings
> + RssShm size of resident shmem memory (includes SysV shm,
> + mapping of tmpfs and shared anonymous mappings)
> VmData size of data, stack, and text segments
> VmStk size of data, stack, and text segments
> VmExe size of text segment
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 9b9708e..7332afd 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -23,9 +23,13 @@
>
> void task_mem(struct seq_file *m, struct mm_struct *mm)
> {
> - unsigned long data, text, lib, swap, ptes, pmds;
> + unsigned long data, text, lib, swap, ptes, pmds, anon, file, shmem;
> unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss;
>
> + anon = get_mm_counter(mm, MM_ANONPAGES);
> + file = get_mm_counter(mm, MM_FILEPAGES);
> + shmem = get_mm_counter(mm, MM_SHMEMPAGES);
> +
> /*
> * Note: to minimize their overhead, mm maintains hiwater_vm and
> * hiwater_rss only when about to *lower* total_vm or rss. Any
> @@ -36,7 +40,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> hiwater_vm = total_vm = mm->total_vm;
> if (hiwater_vm < mm->hiwater_vm)
> hiwater_vm = mm->hiwater_vm;
> - hiwater_rss = total_rss = get_mm_rss(mm);
> + hiwater_rss = total_rss = anon + file + shmem;
> if (hiwater_rss < mm->hiwater_rss)
> hiwater_rss = mm->hiwater_rss;
>
> @@ -53,6 +57,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> "VmPin:\t%8lu kB\n"
> "VmHWM:\t%8lu kB\n"
> "VmRSS:\t%8lu kB\n"
> + "RssAnon:\t%8lu kB\n"
> + "RssFile:\t%8lu kB\n"
> + "RssShm:\t%8lu kB\n"
... but on my terminal that comes out as
VmPeak: 4584 kB
VmSize: 4584 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 1264 kB
VmRSS: 1264 kB
RssAnon: 84 kB
RssFile: 1180 kB
RssShm: 0 kB
VmData: 184 kB
VmStk: 136 kB
VmExe: 48 kB
VmLib: 1808 kB
VmPTE: 32 kB
VmPMD: 12 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
Notice anything ugly about that? Of course, what's really wrong was
the years-ago choice of absurdly short names, with a tab after them.
Ugh. The HugetlbPages line probably can't be helped (even HugeTLB:
would be too long). But your three, I hope we can do better: I can
understand why Rss instead of Vm, sure, Vm on the front contributes
nothing but incorrectness, and it wasn't a bad idea to group them as
contributors to VmRSS.
I suggest either indenting them with spaces to keep the alignment,
" Anon:\t%8lu kB\n"
" File:\t%8lu kB\n"
" Shmem:\t%8lu kB\n"
or keeping your Rss prefix but misaligning the three together,
"RssAnon:\t%8lu kB\n"
"RssFile:\t%8lu kB\n"
"RssShmem:\t%8lu kB\n"
I somewhat prefer "Shmem" to "Shm" because "Shmem" is what
/proc/meminfo already says, and "Shm" makes me think of SysV SHM only.
But I'd happily settle for Shm if it helped in the alignment.
I realize that /proc/<pid>/status is not universally loved for its
aesthetic charm, and I may be the only one who feels this way...
Hugh
> "VmData:\t%8lu kB\n"
> "VmStk:\t%8lu kB\n"
> "VmExe:\t%8lu kB\n"
> @@ -66,6 +73,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> mm->pinned_vm << (PAGE_SHIFT-10),
> hiwater_rss << (PAGE_SHIFT-10),
> total_rss << (PAGE_SHIFT-10),
> + anon << (PAGE_SHIFT-10),
> + file << (PAGE_SHIFT-10),
> + shmem << (PAGE_SHIFT-10),
> data << (PAGE_SHIFT-10),
> mm->stack_vm << (PAGE_SHIFT-10), text, lib,
> ptes >> 10,
> --
> 2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web