From: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
To: "dev@dpdk.org" <dev@dpdk.org>,
Anatoly Burakov <anatoly.burakov@intel.com>
Cc: "Xueming(Steven) Li" <xuemingl@nvidia.com>,
Thomas Monjalon <tmonjalon@nvidia.com>
Subject: [dpdk-dev] Zeroing out memory on free
Date: Tue, 24 Aug 2021 10:58:08 +0000 [thread overview]
Message-ID: <CH0PR12MB50915776AB7F52C39590B487B9C59@CH0PR12MB5091.namprd12.prod.outlook.com> (raw)
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
or with more elaborate tracking of memory dirtiness in MM.
Are there any other reasons why clearing is done the current way?
next reply other threads:[~2021-08-24 10:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 10:58 Dmitry Kozlyuk [this message]
2021-08-25 7:26 ` Thomas Monjalon
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=CH0PR12MB50915776AB7F52C39590B487B9C59@CH0PR12MB5091.namprd12.prod.outlook.com \
--to=dkozlyuk@nvidia.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=tmonjalon@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).