The patch titled
Subject: mm/hugetlb.c: warn the user when issues arise on boot due to hugepages
has been added to the -mm tree. Its filename is
mm-hugetlb-warn-the-user-when-issues-arise-on-boot-due-to-hugepages.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-warn-the-user-when-issues-arise-on-boot-due-to-hugepages.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-warn-the-user-when-issues-arise-on-boot-due-to-hugepages.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx>
Subject: mm/hugetlb.c: warn the user when issues arise on boot due to hugepages
When the user specifies too many hugepages or an invalid
default_hugepagesz the communication to the user is implicit in the
allocation message. This patch adds a warning when the desired page count
is not allocated and prints an error when the default_hugepagesz is
invalid on boot.
During boot hugepages will allocate until there is a fraction of the
hugepage size left. That is, we allocate until either the request is
satisfied or memory for the pages is exhausted. When memory for the pages
is exhausted, it will most likely lead to the system failing with the OOM
manager not finding enough (or anything) to kill (unless you're using
really big hugepages in the order of 100s of MB or in the GBs). The user
will most likely see the OOM messages much later in the boot sequence than
the implicitly stated message. Worse yet, you may even get an OOM for
each processor which causes many pages of OOMs on modern systems.
Although these messages will be printed earlier than the OOM messages, at
least giving the user errors and warnings will highlight the configuration
as an issue. I'm trying to point the user in the right direction by
providing a more robust statement of what is failing.
During the sysctl or echo command, the user can check the results much
easier than if the system hangs during boot and the scenario of having
nothing to OOM for kernel memory is highly unlikely.
Link: http://lkml.kernel.org/r/20170603005413.10380-1-Liam.Howlett@xxxxxxxxxx
Signed-off-by: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
Cc: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
Cc: Gerald Schaefer <gerald.schaefer@xxxxxxxxxx>
Cc: zhongjiang <zhongjiang@xxxxxxxxxx>
Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
Cc: "Kirill A . Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/hugetlb.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff -puN mm/hugetlb.c~mm-hugetlb-warn-the-user-when-issues-arise-on-boot-due-to-hugepages mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-warn-the-user-when-issues-arise-on-boot-due-to-hugepages
+++ a/mm/hugetlb.c
@@ -69,6 +69,7 @@ struct mutex *hugetlb_fault_mutex_table
/* Forward declaration */
static int hugetlb_acct_memory(struct hstate *h, long delta);
+static char * __init memfmt(char *buf, unsigned long n);
static inline void unlock_or_release_subpool(struct hugepage_subpool *spool)
{
@@ -2212,7 +2213,14 @@ static void __init hugetlb_hstate_alloc_
&node_states[N_MEMORY]))
break;
}
- h->max_huge_pages = i;
+ if (i < h->max_huge_pages) {
+ char buf[32];
+
+ memfmt(buf, huge_page_size(h)),
+ pr_warn("HugeTLB: allocating %lu of page size %s failed. Only allocated %lu hugepages.\n",
+ h->max_huge_pages, buf, i);
+ h->max_huge_pages = i;
+ }
}
static void __init hugetlb_init_hstates(void)
@@ -2808,6 +2816,11 @@ static int __init hugetlb_init(void)
return 0;
if (!size_to_hstate(default_hstate_size)) {
+ if (default_hstate_size != 0) {
+ pr_err("HugeTLB: unsupported default_hugepagesz %lu. Reverting to %lu\n",
+ default_hstate_size, HPAGE_SIZE);
+ }
+
default_hstate_size = HPAGE_SIZE;
if (!size_to_hstate(default_hstate_size))
hugetlb_add_hstate(HUGETLB_PAGE_ORDER);
_
Patches currently in -mm which might be from Liam.Howlett@xxxxxxxxxx are
mm-hugetlb-warn-the-user-when-issues-arise-on-boot-due-to-hugepages.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
