DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Anatoly Burakov <anatoly.burakov@intel.com>,
	"Xueming(Steven) Li" <xuemingl@nvidia.com>,
	david.marchand@redhat.com, bruce.richardson@intel.com
Subject: Re: [dpdk-dev] Zeroing out memory on free
Date: Wed, 25 Aug 2021 09:26:51 +0200	[thread overview]
Message-ID: <1730403.MaGYrl2sIR@thomas> (raw)
In-Reply-To: <CH0PR12MB50915776AB7F52C39590B487B9C59@CH0PR12MB5091.namprd12.prod.outlook.com>

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.monroy@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.monroy@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.



  reply	other threads:[~2021-08-25  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-24 10:58 Dmitry Kozlyuk
2021-08-25  7:26 ` Thomas Monjalon [this message]
2021-08-25 11:47   ` Burakov, Anatoly
2021-08-25 12:30     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1730403.MaGYrl2sIR@thomas \
    --to=thomas@monjalon.net \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dkozlyuk@nvidia.com \
    --cc=xuemingl@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).