On Tue, Jul 28, 2015 at 04:30:19PM -0700, David Rientjes wrote:
>
> It's not only the oom killer, I don't believe hugeltb pages are accounted
> to the "rss" in memcg. They use the hugetlb_cgroup for that. Starting to
> account for them in existing memcg deployments would cause them to hit
> their memory limits much earlier. The "rss_huge" field in memcg only
> represents transparent hugepages.
>
> I agree with your comment that having done this when hugetlbfs was
> introduced would have been optimal.
>
> It's always difficult to add a new class of memory to an existing metric
> ("new" here because it's currently unaccounted).
>
> If we can add yet another process metric to track hugetlbfs memory mapped,
> then the test could be converted to use that. I'm not sure if the
> jusitifcation would be strong enough, but you could try.
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?
Jörn
--
The object-oriented version of 'Spaghetti code' is, of course, 'Lasagna code'.
(Too many layers).
-- Roberto Waltman.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>