Поведение, которое вы видите, характерно для версий DPDK до 18.05 или 18.05+ с параметром --legacy-mem. Я собираюсь предположить первое, так как оно более вероятно.
Это происходит потому, что DPDK поддерживает определенную разновидность многопроцессорной обработки, которая позволяет «вторичным» процессам присоединяться к «первичному» процессу даже после того, как он уже завершился. Поскольку DPDK полагается на файлы огромных страниц (в файловой системе hugetlbfs) для совместного использования памяти между его первичным и вторичным процессами, эти файлы огромных страниц не удаляются после выхода из приложения, чтобы позволить вторичным процессам использовать их.
Есть несколько решений этой проблемы. Первый - вам вообще ничего не нужно делать. Если вы опасаетесь, что DPDK не сможет запуститься снова из-за того, что у вас закончились огромные страницы, то это не проблема, потому что DPDK очистит все неиспользуемые огромные страницы перед выделением новых.
Если вы хотите вернуть эту память системе после закрытия процесса, вы можете сделать это вручную. Для этого вам нужно знать, где хранились огромные страницы (т. е. где смонтирован ваш hugetlbfs) — во многих дистрибутивах он по умолчанию смонтирован в /dev/hugepages. Если вы пойдете туда и очистите все файлы rte_* (при условии, что вы используете префикс DPDK по умолчанию, что вы, вероятно, и делаете), все огромные страницы будут возвращены в систему.
Наконец, если вам не нужна многопроцессорность, вы можете использовать параметр --huge-unlink EAL[1] при запуске DPDK. Это сделает так, что какие бы огромные страницы ни выделял DPDK, он сразу же удалит файлы. Затем, когда приложение закрывается, огромные страницы будут автоматически освобождены благодаря закрытию дескрипторов файлов.
В более новых версиях DPDK это менее проблематично, потому что DPDK может динамически увеличивать и уменьшать использование памяти [2]. Я не знаком с DPDK-PROX, поэтому не могу сказать, поддерживает ли он более новые версии DPDK.
[1] https://software.intel.com/en-us/articles/memory-in-dpdk-part-3-1711-and-earlier-releases
[2] https://software.intel.com/en-us/articles/memory-in-dpdk-part-4-1811-and-beyond
person
aburakov
schedule
26.08.2019
