DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: David Harton <dharton@cisco.com>
Cc: dev@dpdk.org, anatoly.burakov@intel.com
Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_zalloc_socket to zero memory
Date: Mon, 10 Dec 2018 03:26:22 -0700	[thread overview]
Message-ID: <20181210102622.GA10896@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20181207222420.9508-1-dharton@cisco.com>

On Fri, Dec 07, 2018 at 05:24:20PM -0500, David Harton wrote:
> The zalloc and calloc functions do not actually zero the memory.
> Added memset to rte_zmalloc_socket() so allocated memory is cleared.
> 
> Signed-off-by: David Harton <dharton@cisco.com>
> ---
>  lib/librte_eal/common/rte_malloc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
> index 0da5ad5e8..be382e534 100644
> --- a/lib/librte_eal/common/rte_malloc.c
> +++ b/lib/librte_eal/common/rte_malloc.c
> @@ -74,7 +74,9 @@ rte_malloc(const char *type, size_t size, unsigned align)
>  void *
>  rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket)
>  {
> -	return rte_malloc_socket(type, size, align, socket);
> +	void *new_ptr = rte_malloc_socket(type, size, align, socket);
> +	if (new_ptr) memset(new_ptr, 0, size);
> +	return new_ptr;
>  }

While this is functionally correct, I believe this memset should not
actually be needed. A few years back we changed the behaviour in DPDK to
always zero memory on free, rather than zeroing on allocate. This worked
fine because the kernel always gave us zeroed hugepages and zeroing them a
second time was a waste of cycles. The percentage of memory that was
subsequently freed and reallocated was small so zeroing on free saved quite
a bit of processing time, especially at app startup.

If, following all the memory rework in recent releases, this scheme of
zeroing on free no longer works, I'd rather see that fixed than go back to
the scheme of zeroing on allocation. [Assuming we do fix it, a comment
explaining the missing memset would also be good to avoid future patches
here]

Regards,
/Bruce

  parent reply	other threads:[~2018-12-10 10:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 22:24 David Harton
2018-12-07 23:41 ` Wiles, Keith
2018-12-07 23:47   ` David Harton (dharton)
2018-12-07 23:51     ` Wiles, Keith
2018-12-07 23:54     ` Wiles, Keith
2018-12-09 19:20 ` Mattias Rönnblom
2018-12-09 20:11 ` [dpdk-dev] [PATCH v2] " David Harton
2018-12-10 16:21   ` Burakov, Anatoly
2018-12-10 10:26 ` Bruce Richardson [this message]
2018-12-10 10:45   ` [dpdk-dev] [PATCH] " Burakov, Anatoly

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=20181210102622.GA10896@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=dharton@cisco.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).