From: Peter Zijlstra <peterz@infradead.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Yunlong Song <yunlong.song@huawei.com>,
dzickus@redhat.com, dsahern@gmail.com, fweisbec@gmail.com,
jmario@redhat.com, efault@gmx.de, paulus@samba.org,
rfowles@redhat.com, eranian@google.com,
"acme@kernel.org >> Arnaldo Carvalho de Melo" <acme@kernel.org>,
mingo@redhat.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jiri Olsa <jolsa@kernel.org>,
"wangnan0@huawei.com >> Wang Nan" <wangnan0@huawei.com>,
fowles@inreach.com, Namhyung Kim <namhyung@kernel.org>,
andi@firstfloor.org
Subject: Re: [Questions] perf c2c: What's the current status of perf c2c?
Date: Wed, 9 Dec 2015 10:34:02 +0100 [thread overview]
Message-ID: <20151209093402.GM6356@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20151209080440.GA17211@krava.brq.redhat.com>
On Wed, Dec 09, 2015 at 09:04:40AM +0100, Jiri Olsa wrote:
> On Wed, Dec 09, 2015 at 12:06:44PM +0800, Yunlong Song wrote:
> > Hi, Don,
> > I am interested in the perf c2c tool, which is introduced in: http://lwn.net/Articles/588866/
> > However, I found that this tool has not been applied to the mainline tree of perf, Why? It was first
> > introduced in Feb. 2014. What's its current status now? Does it have a new version or a repository
> > somewhere else? And does it support Haswell?
>
> hi,
> not sure Don made any progress on this field, but I'm having
> his c2c sources rebased current perf sources ATM.
>
> I changed the tool a little to run over new DATALA events
> added in Haswell (in addition to ldlat events) and it seems
> to work.
>
> the plan for me is to to use it some more to prove it's useful
> and kick it to be merged with perf at some point
So I never really liked the c2c tool because it was so narrowly
focussed, it only works on NUMA thingies IIRC.
I would much rather see a tool that uses PEBS events and does a dwarf
decode of the exact instruction's data reference -- without relying on
data address bits.
That is; suppose we measure LLC_MISS, even if we have a
data-address, as soon as its inside a dynamically allocated object,
you're lost.
However, since we have the exact instruction we can simply look at that.
Imagine something like:
struct foo {
int blah;
int val;
int array[];
};
struct bar {
struct foo *foo;
}
int foobar(struct bar *bar)
{
return bar->foo->val;
}
Which we can imagine could result in code like:
foobar:
mov (%rax), %rax # load bar::foo
mov (%rax,1,4), %rax # load foo::val
And DWARFs should know this, so by knowing the instruction we can know
which load missed the cache.
Once you have this information, you can use pahole like structure output
and heat colour them or whatnot. Bright red if you miss lots etc..
Now currently this is possible but a bit of work because the DWARF
annotations are not exactly following these data types, that is you
might need to decode previous instructions and infer some bits.
I think Stephane was working with GCC people to allow more/better DWARF
annotations and allow easier retrieval of this information.
Note: the proposed scheme still have some holes in, imagine trying to
load an array[] member like:
mov 8(%rax, %rcx, 4), %rcx
This would load the array element indexed by RCX into RCX, thereby
destroying the index. In this case knowing the data address you can
still compute the index if you also know RAX (which you get from the
PEBS register dump).
next prev parent reply other threads:[~2015-12-09 9:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-09 4:06 [Questions] perf c2c: What's the current status of perf c2c? Yunlong Song
2015-12-09 8:04 ` Jiri Olsa
2015-12-09 8:12 ` Wangnan (F)
2015-12-09 9:11 ` Jiri Olsa
2015-12-09 9:34 ` Peter Zijlstra [this message]
2015-12-09 10:58 ` Peter Zijlstra
2015-12-09 11:09 ` Joe Mario
[not found] ` <1891297138.17374838.1449658964938.JavaMail.zimbra@redhat.com>
2015-12-09 14:03 ` Peter Zijlstra
2015-12-09 16:58 ` Andi Kleen
2015-12-09 17:15 ` Stephane Eranian
2015-12-09 17:21 ` Andi Kleen
2015-12-09 19:48 ` Stephane Eranian
2015-12-09 20:41 ` Joe Mario
2015-12-10 2:36 ` Yunlong Song
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=20151209093402.GM6356@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=dsahern@gmail.com \
--cc=dzickus@redhat.com \
--cc=efault@gmx.de \
--cc=eranian@google.com \
--cc=fowles@inreach.com \
--cc=fweisbec@gmail.com \
--cc=jmario@redhat.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
--cc=rfowles@redhat.com \
--cc=wangnan0@huawei.com \
--cc=yunlong.song@huawei.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.