From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Milian Wolff <milian.wolff@kdab.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
Linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH 1/2] perf report: ensure the perf DSO mapping matches what libdw sees
Date: Fri, 2 Jun 2017 16:49:10 -0300 [thread overview]
Message-ID: <20170602194910.GB31764@kernel.org> (raw)
In-Reply-To: <13986004.8uJxbMKobt@agathebauer>
Em Fri, Jun 02, 2017 at 06:21:44PM +0200, Milian Wolff escreveu:
> On Freitag, 2. Juni 2017 17:23:41 CEST Arnaldo Carvalho de Melo wrote:
> > Looks ok, having both implementations matching and the callchains making
> > sense for your workloads is a good way to verify the sanity, thanks.
> > I wonder if we shouldn't somehow script this, i.e. build it with one
> > implementation, generate output from some test workload, build it with
> > the other, second output, diff it, report when not the same.
> That does sound like a good idea, but I'm unsure how to do it. Note that many
> "simple" tests work just fine. Only larger complicated workloads trigger this
> issue for me.
> One potential way to test it would be `perf archive` - i.e. I send you the
> binaries involved and then we can use perf script diffing to ensure it all
> works...
Humm, I'm trying to cook up a:
perf data filter --pid 12345 --perf-data-offset 1234567 --output perf.data.subset
to allow when finding some case like that to get a small subset of a
perf.data file with just the sample we want to get the backtrace from +
the mmaps, etc up to that point.
With that I could keep a repo of interesting perf.data files to have in
my regression tests.
- Arnaldo
next prev parent reply other threads:[~2017-06-02 19:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-02 14:37 [PATCH 1/2] perf report: ensure the perf DSO mapping matches what libdw sees Milian Wolff
2017-06-02 14:37 ` [PATCH 2/2] perf report: report module before querying isactivation in dwfl unwind Milian Wolff
2017-06-02 15:25 ` Arnaldo Carvalho de Melo
2017-06-05 10:47 ` Jiri Olsa
2017-06-15 19:20 ` Jan Kratochvil
2017-06-16 16:06 ` Arnaldo Carvalho de Melo
2017-06-16 17:36 ` Arnaldo Carvalho de Melo
2017-06-16 19:38 ` [tip:perf/urgent] perf unwind: Report " tip-bot for Milian Wolff
2017-06-02 15:23 ` [PATCH 1/2] perf report: ensure the perf DSO mapping matches what libdw sees Arnaldo Carvalho de Melo
2017-06-02 16:21 ` Milian Wolff
2017-06-02 19:49 ` Arnaldo Carvalho de Melo [this message]
2017-06-03 11:36 ` Milian Wolff
2017-06-05 10:41 ` Jiri Olsa
2017-06-15 20:38 ` Jan Kratochvil
2017-06-07 16:01 ` [tip:perf/urgent] perf report: Ensure " tip-bot for Milian Wolff
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=20170602194910.GB31764@kernel.org \
--to=acme@kernel.org \
--cc=Linux-kernel@vger.kernel.org \
--cc=acme@redhat.com \
--cc=jolsa@redhat.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=milian.wolff@kdab.com \
--cc=namhyung@kernel.org \
/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.