
Я настроил Huge Pages для использования с Java, и, похоже, все работает хорошо, хотя у меня есть вопрос по поводу учета в /proc/meminfo. Для иллюстрации
# grep HugePages /proc/meminfo
AnonHugePages: 274432 kB
HugePages_Total: 1008
HugePages_Free: 596
HugePages_Rsvd: 594
HugePages_Surp: 0
Мой вопрос касается цифр "Free" и "Rsvd" - почему они не дают в сумме "Total" 1008? На самом деле они дают в сумме 1190. Что я здесь не понимаю?
решение1
Это потому, что HugePages_rsvd по сути считывается из HugePages_Free. Это значит, что из 596 огромных страниц, которые свободны, 594 уже зарезервированы каким-то приложением для использования. То есть ядро зафиксировало, что эти 594 огромные страницы доступны для приложения.
Если сейчас есть запрос на 3 огромные страницы, то он не будет выполнен, так как для резервирования доступны только 2. Думайте об этом как о вызове malloc(), когда вы резервируете виртуальные страницы памяти для учета VSZ для процесса, но когда процесс фактически использует их, они становятся RSZ (рабочим набором) процесса.
Поскольку огромные страницы всегда находятся в основной памяти, когда приложение запрашивает их, ядро вычитает их из свободного пула и увеличивает счетчик Rsvd.
Это из исходного кода ядра.https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
where:
HugePages_Total is the size of the pool of huge pages.
HugePages_Free is the number of huge pages in the pool that are not yet
allocated.
HugePages_Rsvd is short for "reserved," and is the number of huge pages for
which a commitment to allocate from the pool has been made,
but no allocation has yet been made. Reserved huge pages
guarantee that an application will be able to allocate a
huge page from the pool of huge pages at fault time.
HugePages_Surp is short for "surplus," and is the number of huge pages in
the pool above the value in /proc/sys/vm/nr_hugepages. The
maximum number of surplus huge pages is controlled by
/proc/sys/vm/nr_overcommit_hugepages.