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
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 it only
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
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,
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
>
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
hugepages
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
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, 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 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
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
>
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
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 t
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
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
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. But
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, 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
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 the
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
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
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 the accounting back in 2013.
The test program made it into tree, but the
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 the accounting back in 2013.
The test program made it into tree, but the
24 matches
Mail list logo
