Я настроил 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. Что я здесь не понимаю?
Это потому, что 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.