All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Hall <mhall@mhcomputing.net>
To: Luca Boccassi <lboccass@Brocade.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: DPDK (and rte_*alloc family) friendly Valgrind
Date: Sat, 13 Feb 2016 11:59:42 -0800	[thread overview]
Message-ID: <F2F16DAF-301C-4B93-B34B-AFDF94B01444@mhcomputing.net> (raw)
In-Reply-To: <1455366618.3599.35.camel@brocade.com>

On Feb 13, 2016, at 4:30 AM, Luca Boccassi <lboccass@Brocade.com> wrote:
> I have not, however, implemented support for NUMA sockets. There is no
> such concept inside Valgrind's framework at the moment, so it would be a
> monumental task.

There is a way to mark the mallocs and frees from inside a custom allocator instead of remapping to valgrind's allocator. jemalloc uses this if you enable it. I use jemalloc with my DPDK code for all the variable-sized mallocs as I prefer it to librte_malloc, and valgrind works fine on all those allocs because jemalloc calls the hinter functions. 

include/jemalloc/internal/jemalloc_internal.h
look for #ifdef JEMALLOC_VALGRIND

> This might have an effect on cachegrind though, so it's worth noting and
> bearing it in mind when using cachegrind rather than memcheck.

I am not sure that's much of a limitation really, because nobody would use cachegrind on DPDK code I wouldn't think. Instead you would use freely available VTune for open-source or you would use the perf subsystem to monitor the cache performance counters. The only thing I am aware of that Valgrind does, that the performance hardware cannot also do, is memcheck. Unless I missed anything.

Either way this is very handy to have.

Matthew.

  reply	other threads:[~2016-02-13 19:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-10 22:54 DPDK (and rte_*alloc family) friendly Valgrind Luca Boccassi
2016-02-11  7:34 ` Thomas Monjalon
2016-02-13  6:47   ` Matthew Hall
2016-02-13 12:15     ` Luca Boccassi
2016-02-13 12:30   ` Luca Boccassi
2016-02-13 19:59     ` Matthew Hall [this message]
2016-02-15  9:16     ` 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=F2F16DAF-301C-4B93-B34B-AFDF94B01444@mhcomputing.net \
    --to=mhall@mhcomputing.net \
    --cc=dev@dpdk.org \
    --cc=lboccass@Brocade.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.