24/08/2021 12:58, Dmitry Kozlyuk:
> Hello,
>
> Me and Xueming are wondering why DPDK clears the memory on free
> and not only when it's explicitly requested (rte_zmalloc).
>
> It's been so for a while:
>
> commit ea0bddbd14e68fb42d9774bc3543e51b510e48d3
> Author: Sergio Gonzalez Monroy <sergio.gonzalez.mon...@intel.com>
> Date: Tue Jul 5 12:01:15 2016 +0100
>
> mem: zero out memory on free
>
> Since commit fafcc11985a2, memzones are not guaranteed to be zeroed out.
> This could potentially cause issues as applications might have been
> relying on the allocated memory being zeroed out.
>
> On init all allocated memory is zeroed by the kernel, so by zeroing out
> memory on free, all available dpdk memory is always zeroed.
>
> Fixes: fafcc11985a2 ("mem: rework memzone to be allocated by malloc")
>
> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.mon...@intel.com>
>
> At present this explanation doesn't look satisfying:
> 1. Memzone API does not promise they will be zeroed out.
> Memzones are mostly used for DMA, so their content will likely be
> overwritten.
> 2. If application assumptions are wrong, DPDK should not try to fix it.
> Memory manager poisons memory in debug mode to detect such errors.
>
> Zeroing memory is quite slow, but in many cases unneeded.
> It looks attractive to only do it in rte_zmalloc().
> AFAIK what prohibits moving memset() there unconditionally
> is that the kernel already gives us cleared pages,
> so the first allocation of each piece of memory would do unnecessary work.
> This can be solved by giving the user a choice in EAL options
No I don't think it should be workarounded in EAL options.
> or with more elaborate tracking of memory dirtiness in MM.
Looks a good idea.
> Are there any other reasons why clearing is done the current way?
I think the only reason was to avoid doing reset for the first usage.
You're right it is not optimal when reusing memory
without any zeroing need.
