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>
---
mm/hugetlb.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f33bb31..c67dd0f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1111,6 +1111,14 @@ static void __init gather_bootmem_prealloc(void)
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;
}
}
--
1.7.4.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>