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: Fri, 31 Jul 2015 14:09:07 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1507311358541.5910@chino.kir.corp.google.com> (raw)
In-Reply-To: <20150730213412.GF17882@Sligo.logfs.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2617 bytes --]
On Thu, 30 Jul 2015, Jörn Engel wrote:
> > If I want to track hugetlb usage on a per-task basis, do I then need to
> > create one cgroup per task?
> >
I think this would only be used for debugging or testing, but if you have
root and are trying to organize processes into a hugetlb_cgroup hierarchy,
presumably you would just look at smaps and find each thread's hugetlb
memory usage and not bother.
> Maybe some background is useful. I would absolutely love to use
> transparent hugepages. They are absolutely perfect in every respect,
> except for performance. With transparent hugepages we get higher
> latencies. Small pages are unacceptable, so we are forced to use
> non-transparent hugepages.
>
Believe me, we are on the same page that way :) We still deploy
configurations with hugetlb memory because we need to meet certain
allocation requirements and it is only possible to do at boot.
With regard to the performance of thp, I can think of two things that are
affecting you:
- allocation cost
Async memory compaction in the page fault path for thp memory is very
lightweight and it happily falls back to using small pages instead.
Memory compaction is always being improved upon and there is on-going
work to do memory compaction both periodically and in the background to
keep fragmentation low. The ultimate goal would be to remove async
compaction entirely from the thp page fault path and rely on
improvements to memory compaction such that we have a great allocation
success rate and less cost when we fail.
- NUMA cost
Until very recently, thp pages could easily be allocated remotely
instead of small pages locally. That has since been improved and we
only allocate thp locally and then fallback to small pages locally
first. Khugepaged can still migrate memory remotely, but it will
allocate the hugepage on the node where the majority of smallpages
are from.
> The part of our system that uses small pages is pretty much constant,
> while total system memory follows Moore's law. When possible we even
> try to shrink that part. Hugepages already dominate today and things
> will get worse.
>
I wrote a patchset, hugepages overcommit, that allows unmapped hugetlb
pages to be freed in oom conditions before calling the oom killer up to a
certain threshold and then kickoff a background thread to try to
reallocate them. The idea is to keep the hugetlb pool as large as
possible up to oom and then only reclaim what is needed and then try to
reallocate them. Not sure if it would help your particular usecase or
not.
next prev parent reply other threads:[~2015-07-31 21:09 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 [this message]
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
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=alpine.DEB.2.10.1507311358541.5910@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;
as well as URLs for NNTP newsgroup(s).