Re: hugetlb pages not accounted for in rss

David Rientjes
2015-07-28T22:15:21Z

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.