I am not sure if this is a bug or simply part of the design so please, bear with me. :) I noticed that whenever application - which uses DPDK's mem components for mapping hugepages - exits there's always one hugepages backing file left under hugetlbfs mount. Specifically, it's the file that's mapped under the very begging of the address space. E.g. where base-virtaddr is set to 0x200000000000: 200000200000-200000400000 rw-s 00000000 00:29 18115803 /dev/hugepages/spdk_pid1806446map_0 When the unlinking starts upon existing, everything down to map1 (0x200000400000) is unlinked but map0 remains. This is not the case when --huge-unlink is used during the init part (all backing files are unlinked at the start then, including map0). This doesn't seem to be a big deal in itself, but depending on what size of hugepages we are using this may leave different footprint (e.g. we start 3 apps simultaneously, each one uses 1G hugepages. When they all exit, 3G of hugepages may be still in use). I can see that there's also a cleanup routine which is fired upon starting the app, to make sure that any lingering backing files are removed, but still. :) Any hints on why this might be the case would be appreciated. :)
It depends, but most likely reason for this is a memory leak of some sort. Generally, when primary process deinitializes, not everything gets unmapped because the expectation is that other processes might still be active and keep references to some of that memory. Additionally, some things may intentionally leak memory (e.g. RX callbacks in ethdev) because it is generally impossible to not leak it safely. I would advise adding a rte_malloc_heap_dump() call right after rte_eal_cleanup() and see if anything is still allocated - that's usually the reason why the first page isn't unmapped.
Can you try Anatoly's suggestion?