25/08/2021 13:47, Burakov, Anatoly:
> On 25-Aug-21 8:26 AM, Thomas Monjalon wrote:
> > 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.
> >
>
> You said it yourself: zeroing out memory is quite slow. This was pretty
> much done for performance reasons - memory is released way less often
> than allocated, and we get memory from the kernel that is *always*
> zeroed out in case of hugepages, so we don't need to zero them out
> initially. So, in essence, this allows us to always keeps memory zeroed
> out without worrying about doing that for every allocation.
Anatoly, what do you think about the idea above
(marking initial state as clean, and zero on allocations only if needed)?
