From: David Rientjes <rientjes@google.com>
To: "Jörn Engel" <joern@purestorage.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: hugetlb pages not accounted for in rss
Date: Wed, 29 Jul 2015 12:08:05 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1507291205590.24373@chino.kir.corp.google.com> (raw)
In-Reply-To: <20150729005332.GB17938@Sligo.logfs.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1005 bytes --]
On Tue, 28 Jul 2015, Jorn Engel wrote:
> Well, we definitely need something. Having a 100GB process show 3GB of
> rss is not very useful. How would we notice a memory leak if it only
> affects hugepages, for example?
>
Since the hugetlb pool is a global resource, it would also be helpful to
determine if a process is mapping more than expected. You can't do that
just by adding a huge rss metric, however: if you have 2MB and 1GB
hugepages configured you wouldn't know if a process was mapping 512 2MB
hugepages or 1 1GB hugepage.
That's the purpose of hugetlb_cgroup, after all, and it supports usage
counters for all hstates. The test could be converted to use that to
measure usage if configured in the kernel.
Beyond that, I'm not sure how a per-hstate rss metric would be exported to
userspace in a clean way and other ways of obtaining the same data are
possible with hugetlb_cgroup. I'm not sure how successful you'd be in
arguing that we need separate rss counters for it.
next prev parent reply other threads:[~2015-07-29 19:08 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 23:26 Mike Kravetz
2015-07-28 18:32 ` Jörn Engel
2015-07-28 21:15 ` Mike Kravetz
2015-07-28 22:15 ` David Rientjes
2015-07-28 22:26 ` Jörn Engel
2015-07-28 23:30 ` David Rientjes
2015-07-29 0:53 ` Jörn Engel
2015-07-29 19:08 ` David Rientjes [this message]
2015-07-29 23:20 ` Mike Kravetz
2015-07-30 21:34 ` Jörn Engel
2015-07-31 21:09 ` David Rientjes
2015-08-04 2:55 ` Naoya Horiguchi
2015-08-04 5:13 ` [PATCH] smaps: fill missing fields for vma(VM_HUGETLB) Naoya Horiguchi
2015-08-04 18:21 ` Jörn Engel
2015-08-06 2:18 ` David Rientjes
2015-08-06 7:44 ` Naoya Horiguchi
2015-08-07 7:24 ` [PATCH v2 0/2] hugetlb: display per-process/per-vma usage Naoya Horiguchi
2015-08-07 7:24 ` [PATCH v2 2/2] mm: hugetlb: add VmHugetlbRSS: field in /proc/pid/status Naoya Horiguchi
2015-08-07 22:55 ` Andrew Morton
2015-08-10 0:47 ` Naoya Horiguchi
2015-08-10 0:47 ` [PATCH v3 1/3] smaps: fill missing fields for vma(VM_HUGETLB) Naoya Horiguchi
2015-08-10 0:47 ` [PATCH v3 2/3] mm: hugetlb: add VmHugetlbRSS: field in /proc/pid/status Naoya Horiguchi
2015-08-10 1:16 ` Naoya Horiguchi
2015-08-10 0:47 ` [PATCH v3 3/3] Documentation/filesystems/proc.txt: document hugetlb RSS Naoya Horiguchi
2015-08-11 0:44 ` David Rientjes
2015-08-12 0:03 ` Naoya Horiguchi
2015-08-12 7:45 ` [PATCH v4 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps Naoya Horiguchi
2015-08-12 7:45 ` [PATCH v4 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status Naoya Horiguchi
2015-08-12 20:30 ` David Rientjes
2015-08-13 0:45 ` Naoya Horiguchi
2015-08-13 21:14 ` Jörn Engel
2015-08-13 21:13 ` Jörn Engel
2015-08-17 21:28 ` David Rientjes
2015-08-12 20:25 ` [PATCH v4 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps David Rientjes
2015-08-13 21:14 ` Jörn Engel
2015-08-20 8:26 ` [PATCH v5 0/2] hugetlb: display per-process/per-vma usage Naoya Horiguchi
2015-08-20 8:26 ` [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps Naoya Horiguchi
2015-08-20 10:49 ` Michal Hocko
2015-08-20 23:20 ` Naoya Horiguchi
2015-08-21 6:33 ` Michal Hocko
2015-09-07 1:29 ` Pádraig Brady
2015-09-07 2:23 ` Naoya Horiguchi
2015-09-07 6:46 ` Naoya Horiguchi
2015-09-07 9:52 ` Pádraig Brady
2015-09-07 10:52 ` Pádraig Brady
2015-09-17 9:39 ` Naoya Horiguchi
2015-09-09 15:12 ` Vlastimil Babka
2015-09-09 22:14 ` David Rientjes
2015-08-20 8:26 ` [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status Naoya Horiguchi
2015-08-20 11:00 ` Michal Hocko
2015-08-20 19:49 ` David Rientjes
2015-08-21 6:32 ` Michal Hocko
2015-08-21 16:38 ` Jörn Engel
2015-08-20 23:34 ` Naoya Horiguchi
2015-08-21 6:53 ` Michal Hocko
2015-08-21 16:30 ` Jörn Engel
2015-08-24 8:51 ` Michal Hocko
2015-08-25 23:23 ` David Rientjes
2015-08-26 6:38 ` Michal Hocko
2015-08-26 22:02 ` David Rientjes
2015-08-27 6:48 ` Michal Hocko
2015-08-27 17:23 ` Jörn Engel
2015-08-27 20:44 ` David Rientjes
2015-08-31 9:12 ` Michal Hocko
2015-09-16 0:21 ` [PATCH v1] mm: migrate: hugetlb: putback destination hugepage to active list Naoya Horiguchi
2015-09-16 2:53 ` Naoya Horiguchi
2015-08-07 7:24 ` [PATCH v2 1/2] smaps: fill missing fields for vma(VM_HUGETLB) Naoya Horiguchi
2015-08-07 22:50 ` Andrew Morton
2015-08-11 0:37 ` David Rientjes
2015-08-11 23:32 ` Naoya Horiguchi
2015-08-11 23:48 ` David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.10.1507291205590.24373@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=joern@purestorage.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox