The patch titled
mm: fix negative commitlimit when gigantic hugepages are allocated
has been added to the -mm tree. Its filename is
mm-fix-negative-commitlimit-when-gigantic-hugepages-are-allocated.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 ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: mm: fix negative commitlimit when gigantic hugepages are allocated
From: Rafael Aquini <aquini@xxxxxxxxx>
When 1GB hugepages are allocated on a system, free(1) reports less
available memory than what really is installed in the box. Also, if the
total size of hugepages allocated on a system is over half of the total
memory size, CommitLimit becomes a negative number.
The problem is that gigantic hugepages (order > MAX_ORDER) can only be
allocated at boot with bootmem, thus its frames are not accounted to
'totalram_pages'. However, they are accounted to hugetlb_total_pages()
What happens to turn CommitLimit into a negative number is this
calculation, in fs/proc/meminfo.c:
allowed = ((totalram_pages - hugetlb_total_pages())
* sysctl_overcommit_ratio / 100) + total_swap_pages;
A similar calculation occurs in __vm_enough_memory() in mm/mmap.c.
Also, every vm statistic which depends on 'totalram_pages' will render
confusing values, as if system were 'missing' some part of its memory.
Reported-by: Russ Anderson <rja@xxxxxxx>
Signed-off-by: Rafael Aquini <aquini@xxxxxxxxx>
Acked-by: Russ Anderson <rja@xxxxxxx>
Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
Cc: Christoph Lameter <cl@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/hugetlb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN mm/hugetlb.c~mm-fix-negative-commitlimit-when-gigantic-hugepages-are-allocated mm/hugetlb.c
--- a/mm/hugetlb.c~mm-fix-negative-commitlimit-when-gigantic-hugepages-are-allocated
+++ a/mm/hugetlb.c
@@ -1111,6 +1111,14 @@ static void __init gather_bootmem_preall
WARN_ON(page_count(page) != 1);
prep_compound_huge_page(page, h->order);
prep_new_huge_page(h, page, page_to_nid(page));
+
+ /* if we had gigantic hugepages allocated at boot time,
+ * we need to reinstate the 'stolen' pages to totalram_pages,
+ * in order to fix confusing memory reports from free(1)
+ * and another side-effects, like CommitLimit going negative.
+ */
+ if (h->order > (MAX_ORDER - 1))
+ totalram_pages += 1 << h->order;
}
}
_
Patches currently in -mm which might be from aquini@xxxxxxxxx are
mm-fix-negative-commitlimit-when-gigantic-hugepages-are-allocated.patch
mm-fix-negative-commitlimit-when-gigantic-hugepages-are-allocated-fix.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
