CentOs7: HugePages_Rsvd 等于 18446744073709551615

CentOs7: HugePages_Rsvd equals 18446744073709551615

为了 DPDK,我有一个使用大量大页面的应用程序。我在系统启动时分配页面,然后 load/unload 多次分配应用程序。 重新加载后,程序无法再分配大页面。当我查看 meminfo 时,我看到:

HugePages_Total:    2656
HugePages_Free:     1504
HugePages_Rsvd:     18446744073709551615   
HugePages_Surp:        0

这将保持这种方式,并且不会让任何应用程序分配大页面,直到我重新启动机器。

有什么想法吗?

decrement_hugepage_resv_vma 函数尝试 -1 为 resv_huge_pages, 但是无符号算术导致它变成 ULONG_MAX (unsigned long resv_huge_pages),在 64 位系统上是 18446744073709551615。

alloc_huge_page()
    page = dequeue_huge_page_vma(h, vma, addr, avoid_reserve)
        decrement_hugepage_resv_vma() {
            h->resv_huge_pages--;
        }

static void return_unused_surplus_pages(struct hstate *h,
                    unsigned long unused_resv_pages)
{
    h->resv_huge_pages -= unused_resv_pages;
}

其他几率较小的原因是 gather_surplus_pages() 函数会溢出 resv_huge_pages。

在测试期间尝试下一步:

while [  1  ] ; do date | awk '{print }' >> HugePages_Rsvd.log; cat /proc/meminfo | grep HugePages_Rsvd >> HugePages_Rsvd.log; sleep 1;  done

我猜如果 resv_huge_pages 会缓慢增加所以问题在 h->resv_huge_pages += delta;

但是如果resv_huge_pages突然变成-1(unsigned long == 18446744073709551615)那么问题在h->resv_huge_pages--; (resv_huge_pages 是 0 并且递减 == -1)

取决于你的内核你可以检查补丁 mm: numa: 禁用 vma 的更改保护(VM_HUGETLB) 6b79c57b92cdd90853002980609af516d14c4f9c 和 BUG large value for HugePages_Rsvd