On Wed, Jul 29, 2015 at 04:20:59PM -0700, Mike Kravetz wrote:
> On 07/29/2015 12:08 PM, David Rientjes wrote:
> >On Tue, 28 Jul 2015, Jörn Engel wrote:
> >
> >>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 i
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 hierar
On Wed, Jul 29, 2015 at 04:20:59PM -0700, Mike Kravetz wrote:
> >
> >Since the hugetlb pool is a global resource, it would also be helpful to
> >determine if a process is mapping more than expected. You can't do that
> >just by adding a huge rss metric, however: if you have 2MB and 1GB
> >hugepage
On 07/29/2015 12:08 PM, David Rientjes wrote:
On Tue, 28 Jul 2015, Jörn Engel wrote:
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?
Since the hugetlb pool is a globa
On Tue, 28 Jul 2015, Jörn Engel wrote:
> 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?
>
Since the hugetlb pool is a global resource, it would also be helpful to
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
> t
On Tue, 28 Jul 2015, Jörn Engel wrote:
> What would you propose for me then? I have 80% RAM or more in reserved
> hugepages. OOM-killer is not a concern, as it panics the system - the
> alternatives were almost universally silly and we didn't want to deal
> with system in unpredictable states.
On Tue, Jul 28, 2015 at 03:15:17PM -0700, David Rientjes wrote:
>
> 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.
What would you propose for me then? I have
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
On 07/28/2015 11:32 AM, Jörn Engel wrote:
On Mon, Jul 27, 2015 at 04:26:47PM -0700, Mike Kravetz wrote:
I started looking at the hugetlb self tests. The test hugetlbfstest
expects hugetlb pages to be accounted for in rss. However, there is
no code in the kernel to do this accounting.
It looks
On Mon, Jul 27, 2015 at 04:26:47PM -0700, Mike Kravetz wrote:
> I started looking at the hugetlb self tests. The test hugetlbfstest
> expects hugetlb pages to be accounted for in rss. However, there is
> no code in the kernel to do this accounting.
>
> It looks like there was an effort to add th
11 matches
Mail list logo
