From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: "Jörn Engel" <joern@purestorage.com>,
"Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Mike Kravetz" <mike.kravetz@oracle.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Naoya Horiguchi" <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status
Date: Thu, 27 Aug 2015 08:48:18 +0200 [thread overview]
Message-ID: <20150827064817.GB14367@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1508261451540.19139@chino.kir.corp.google.com>
On Wed 26-08-15 15:02:49, David Rientjes wrote:
> On Wed, 26 Aug 2015, Michal Hocko wrote:
>
> > I thought the purpose was to give the amount of hugetlb based
> > resident memory.
>
> Persistent hugetlb memory is always resident, the goal is to show what is
> currently mapped.
>
> > At least this is what Jorn was asking for AFAIU.
> > /proc/<pid>/status should be as lightweight as possible. The current
> > implementation is quite heavy as already pointed out. So I am really
> > curious whether this is _really_ needed. I haven't heard about a real
> > usecase except for top displaying HRss which doesn't need the break
> > down values. You have brought that up already
> > http://marc.info/?l=linux-mm&m=143941143109335&w=2 and nobody actually
> > asked for it. "I do not mind having it" is not an argument for inclusion
> > especially when the implementation is more costly and touches hot paths.
> >
>
> It iterates over HUGE_MAX_HSTATE and reads atomic usage counters twice.
I am not worried about /proc/<pid>/status read path. That one is indeed
trivial.
> On x86, HUGE_MAX_HSTATE == 2. I don't consider that to be expensive.
>
> If you are concerned about the memory allocation of struct hugetlb_usage,
> it could easily be embedded directly in struct mm_struct.
Yes I am concerned about that and
9 files changed, 112 insertions(+), 1 deletion(-)
for something that is even not clear to be really required. And I still
haven't heard any strong usecase to justify it.
Can we go with the single and much simpler cumulative number first and
only add the break down list if it is _really_ required? We can even
document that the future version of /proc/<pid>/status might add an
additional information to prepare all the parsers to be more careful.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-08-27 6:48 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 23:26 hugetlb pages not accounted for in rss 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
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 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 [this message]
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-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-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=20150827064817.GB14367@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=joern@purestorage.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=nao.horiguchi@gmail.com \
--cc=rientjes@google.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