linux-kernel - Re: hugetlb pages not accounted for in rss

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1507281509420.23577@chino.kir.corp.google.com>
Date:	Tue, 28 Jul 2015 15:15:17 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Mike Kravetz <mike.kravetz@...cle.com>
cc:	Jörn Engel <joern@...estorage.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: hugetlb pages not accounted for in rss

On Tue, 28 Jul 2015, Mike Kravetz wrote:

> > > The easiest way to resolve this issue would be to remove the test and
> > > perhaps document that hugetlb pages are not accounted for in rss.
> > > However, it does seem like a big oversight that hugetlb pages are not
> > > accounted for in rss.  From a quick scan of the code it appears THP
> > > pages are properly accounted for.
> > > 
> > > Thoughts?
> > 
> > Unsurprisingly I agree that hugepages should count towards rss.  Keeping
> > the test in keeps us honest.  Actually fixing the issue would make us
> > honest and correct.
> > 
> > Increasingly we have tiny processes (by rss) that actually consume large
> > fractions of total memory.  Makes rss somewhat useless as a measure of
> > anything.
> 
> I'll take a look at what it would take to get the accounting in place.

I'm not sure that I would agree that accounting hugetlb pages in rss would 
always be appropriate.

For reserved hugetlb pages, not surplus, the hugetlb pages are always 
resident even when unmapped.  Unmapping the memory is not going to cause 
them to be freed.  That's different from thp where the hugepages are 
actually freed when you do munmap().

The oom killer looks at rss as the metric to determine which process to 
kill that will result in a large amount of memory freeing.  If hugetlb 
pages are accounted in rss, this may lead to unnecessary killing since 
little memory may be freed as a result.

For that reason, we've added hugetlb statistics to the oom killer output 
since we've been left wondering in the past where all the memory on the 
system went :)

We also have a separate hugetlb cgroup that tracks hugetlb memory usage 
rather than memcg.

Starting to account hugetlb pages in rss may lead to breakage in userspace 
and I would agree with your earlier suggestion that just removing any test 
for rss would be appropriate.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/