malloc: fix allocation of almost hugepage size
[dpdk.git] / doc / guides / prog_guide / env_abstraction_layer.rst
index 3391e29..5f0748f 100644 (file)
@@ -283,6 +283,18 @@ to prevent data leaks from previous users of the same hugepage.
 EAL ensures this behavior by removing existing backing files at startup
 and by recreating them before opening for mapping (as a precaution).
 
+One exception is ``--huge-unlink=never`` mode.
+It is used to speed up EAL initialization, usually on application restart.
+Clearing memory constitutes more than 95% of hugepage mapping time.
+EAL can save it by remapping existing backing files
+with all the data left in the mapped hugepages ("dirty" memory).
+Such segments are marked with ``RTE_MEMSEG_FLAG_DIRTY``.
+Memory allocator detects dirty segments and handles them accordingly,
+in particular, it clears memory requested with ``rte_zmalloc*()``.
+In this mode EAL also does not remove a backing file
+when all pages mapped from it are freed,
+because they are intended to be reusable at restart.
+
 Anonymous mapping does not allow multi-process architecture.
 This mode does not use hugetlbfs
 and thus does not require root permissions for memory management
@@ -959,6 +971,7 @@ to be virtually contiguous.
 *   dirty - this flag is only meaningful when ``state`` is ``FREE``.
     It indicates that the content of the element is not fully zero-filled.
     Memory from such blocks must be cleared when requested via ``rte_zmalloc*()``.
+    Dirty elements only appear with ``--huge-unlink=never``.
 
 *   pad - this holds the length of the padding present at the start of the block.
     In the case of a normal block header, it is added to the address of the end