From: Jan Stancek <jstancek@redhat.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: mike.kravetz@oracle.com, hillf.zj@alibaba-inc.com,
dave.hansen@linux.intel.com, kirill.shutemov@linux.intel.com,
mhocko@suse.cz, n-horiguchi@ah.jp.nec.com,
aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com
Subject: [bug/regression] libhugetlbfs testsuite failures and OOMs eventually kill my system
Date: Thu, 13 Oct 2016 14:19:00 +0200 [thread overview]
Message-ID: <57FF7BB4.1070202@redhat.com> (raw)
Hi,
I'm running into ENOMEM failures with libhugetlbfs testsuite [1] on
a power8 lpar system running 4.8 or latest git [2]. Repeated runs of
this suite trigger multiple OOMs, that eventually kill entire system,
it usually takes 3-5 runs:
* Total System Memory......: 18024 MB
* Shared Mem Max Mapping...: 320 MB
* System Huge Page Size....: 16 MB
* Available Huge Pages.....: 20
* Total size of Huge Pages.: 320 MB
* Remaining System Memory..: 17704 MB
* Huge Page User Group.....: hugepages (1001)
I see this only on ppc (BE/LE), x86_64 seems unaffected and successfully
ran the tests for ~12 hours.
Bisect has identified following patch as culprit:
commit 67961f9db8c477026ea20ce05761bde6f8bf85b0
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date: Wed Jun 8 15:33:42 2016 -0700
mm/hugetlb: fix huge page reserve accounting for private mappings
Following patch (made with my limited insight) applied to
latest git [2] fixes the problem for me:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ec49d9e..7261583 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1876,7 +1876,7 @@ static long __vma_reservation_common(struct hstate *h,
* return value of this routine is the opposite of the
* value returned from reserve map manipulation routines above.
*/
- if (ret)
+ if (ret >= 0)
return 0;
else
return 1;
Regards,
Jan
[1] https://github.com/libhugetlbfs/libhugetlbfs
[2] v4.8-14230-gb67be92
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Stancek <jstancek@redhat.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: mike.kravetz@oracle.com, hillf.zj@alibaba-inc.com,
dave.hansen@linux.intel.com, kirill.shutemov@linux.intel.com,
mhocko@suse.cz, n-horiguchi@ah.jp.nec.com,
aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com
Subject: [bug/regression] libhugetlbfs testsuite failures and OOMs eventually kill my system
Date: Thu, 13 Oct 2016 14:19:00 +0200 [thread overview]
Message-ID: <57FF7BB4.1070202@redhat.com> (raw)
Hi,
I'm running into ENOMEM failures with libhugetlbfs testsuite [1] on
a power8 lpar system running 4.8 or latest git [2]. Repeated runs of
this suite trigger multiple OOMs, that eventually kill entire system,
it usually takes 3-5 runs:
* Total System Memory......: 18024 MB
* Shared Mem Max Mapping...: 320 MB
* System Huge Page Size....: 16 MB
* Available Huge Pages.....: 20
* Total size of Huge Pages.: 320 MB
* Remaining System Memory..: 17704 MB
* Huge Page User Group.....: hugepages (1001)
I see this only on ppc (BE/LE), x86_64 seems unaffected and successfully
ran the tests for ~12 hours.
Bisect has identified following patch as culprit:
commit 67961f9db8c477026ea20ce05761bde6f8bf85b0
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date: Wed Jun 8 15:33:42 2016 -0700
mm/hugetlb: fix huge page reserve accounting for private mappings
Following patch (made with my limited insight) applied to
latest git [2] fixes the problem for me:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ec49d9e..7261583 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1876,7 +1876,7 @@ static long __vma_reservation_common(struct hstate *h,
* return value of this routine is the opposite of the
* value returned from reserve map manipulation routines above.
*/
- if (ret)
+ if (ret >= 0)
return 0;
else
return 1;
Regards,
Jan
[1] https://github.com/libhugetlbfs/libhugetlbfs
[2] v4.8-14230-gb67be92
next reply other threads:[~2016-10-13 12:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 12:19 Jan Stancek [this message]
2016-10-13 12:19 ` [bug/regression] libhugetlbfs testsuite failures and OOMs eventually kill my system Jan Stancek
2016-10-13 15:24 ` Mike Kravetz
2016-10-13 15:24 ` Mike Kravetz
2016-10-13 23:26 ` Mike Kravetz
2016-10-13 23:26 ` Mike Kravetz
2016-10-14 8:48 ` Jan Stancek
2016-10-14 8:48 ` Jan Stancek
2016-10-14 23:57 ` Mike Kravetz
2016-10-14 23:57 ` Mike Kravetz
2016-10-17 5:04 ` Aneesh Kumar K.V
2016-10-17 5:04 ` Aneesh Kumar K.V
2016-10-17 22:53 ` Mike Kravetz
2016-10-17 22:53 ` Mike Kravetz
2016-10-18 1:18 ` Mike Kravetz
2016-10-18 1:18 ` Mike Kravetz
2016-10-17 14:44 ` Jan Stancek
2016-10-17 14:44 ` Jan Stancek
2016-10-17 18:27 ` Aneesh Kumar K.V
2016-10-17 18:27 ` Aneesh Kumar K.V
2016-10-17 23:19 ` Mike Kravetz
2016-10-17 23:19 ` Mike Kravetz
2016-10-18 8:31 ` Aneesh Kumar K.V
2016-10-18 8:31 ` Aneesh Kumar K.V
2016-10-18 11:28 ` Jan Stancek
2016-10-18 11:28 ` Jan Stancek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57FF7BB4.1070202@redhat.com \
--to=jstancek@redhat.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dave.hansen@linux.intel.com \
--cc=hillf.zj@alibaba-inc.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.