[PATCH v3 3/6] mem: add dirty malloc element support

[Burakov, Anatoly]

On 03-Feb-22 6:13 PM, Dmitry Kozlyuk wrote:
> EAL malloc layer assumed all free elements content
> is filled with zeros ("clean"), as opposed to uninitialized ("dirty").
> This assumption was ensured in two ways:
> 1. EAL memalloc layer always returned clean memory.
> 2. Freed memory was cleared before returning into the heap.
> 
> Clearing the memory can be as slow as around 14 GiB/s.
> To save doing so, memalloc layer is allowed to return dirty memory.
> Such segments being marked with RTE_MEMSEG_FLAG_DIRTY.
> The allocator tracks elements that contain dirty memory
> using the new flag in the element header.
> When clean memory is requested via rte_zmalloc*()
> and the suitable element is dirty, it is cleared on allocation.
> When memory is deallocated, the freed element is joined
> with adjacent free elements, and the dirty flag is updated:
> 
> a) If the joint element contains dirty parts, it is dirty:
> 
>      dirty + freed + dirty = dirty  =>  no need to clean
>              freed + dirty = dirty      the freed memory
> 
>     Dirty parts may be large (e.g. initial allocation),
>     so clearing them could create unpredictable slowdown.
> 
> b) If the only dirty part of the joint element
>     is the freed memory, the joint element can be made clean:
> 
>      clean + freed + clean = clean  =>  freed memory
>      clean + freed         = clean      must be cleared
>              freed + clean = clean
>              freed         = clean
> 
>     This logic naturally reproduces the old behavior
>     and always applies in modes when EAL memalloc layer
>     returns only clean segments.
> 
> As a result, memory is either cleared on free, as before,
> or it will be cleared on allocation if need be, but never twice.
> 
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk at nvidia.com>
> ---

Reviewed-by: Anatoly Burakov <anatoly.burakov at intel.com>

-- 
Thanks,
Anatoly