From: Andi Kleen <ak@linux•intel.com>
To: Ingo Molnar <mingo@kernel•org>
Cc: Jiri Olsa <jolsa@redhat•com>, Namhyung Kim <namhyung@kernel•org>,
Sukadev Bhattiprolu <sukadev@linux•vnet.ibm.com>,
Ingo Molnar <mingo@redhat•com>,
Michael Ellerman <mpe@ellerman•id.au>,
Arnaldo Carvalho de Melo <acme@kernel•org>,
Paul Mackerras <paulus@samba•org>,
linuxppc-dev@lists•ozlabs.org,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>
Subject: Re: [PATCH 2/4] perf: jevents: Program to convert JSON file to C style file
Date: Thu, 28 May 2015 08:39:11 -0700 [thread overview]
Message-ID: <20150528153911.GO7484@tassilo.jf.intel.com> (raw)
In-Reply-To: <20150528130724.GA8987@gmail.com>
> So instead of this flat structure, there should at minimum be broad categorization
> of the various parts of the hardware they relate to: whether they relate to the
> branch predictor, memory caches, TLB caches, memory ops, offcore, decoders,
> execution units, FPU ops, etc., etc. - so that they can be queried via 'perf
> list'.
The categorization is generally on the stem name, which already works fine with
the existing perf list wildcard support. So for example you only want
branches.
perf list br*
...
br_inst_exec.all_branches
[Speculative and retired branches]
br_inst_exec.all_conditional
[Speculative and retired macro-conditional branches]
br_inst_exec.all_direct_jmp
[Speculative and retired macro-unconditional branches excluding calls and indirects]
br_inst_exec.all_direct_near_call
[Speculative and retired direct near calls]
br_inst_exec.all_indirect_jump_non_call_ret
[Speculative and retired indirect branches excluding calls and returns]
br_inst_exec.all_indirect_near_return
[Speculative and retired indirect return branches]
...
Or mid level cache events:
perf list l2*
...
l2_l1d_wb_rqsts.all
[Not rejected writebacks from L1D to L2 cache lines in any state]
l2_l1d_wb_rqsts.hit_e
[Not rejected writebacks from L1D to L2 cache lines in E state]
l2_l1d_wb_rqsts.hit_m
[Not rejected writebacks from L1D to L2 cache lines in M state]
l2_l1d_wb_rqsts.miss
[Count the number of modified Lines evicted from L1 and missed L2. (Non-rejected WBs from the DCU.)]
l2_lines_in.all
[L2 cache lines filling L2]
...
There are some exceptions, but generally it works this way.
The stem could be put into a separate header, but it would seem redundant to me.
> We don't just want the import the unstructured mess that these event files are -
> we want to turn them into real structure. We can still keep the messy vendor names
> as well, like IDQ.DSB_CYCLES, but we want to impose structure as well.
The vendor names directly map to the micro architecture, which is whole
point of the events. IDQ is a part of the CPU, and is described in the
CPU manuals. One of the main motivations for adding event lists is to make
perf match to that documentation.
>
> 3)
>
> There should be good 'perf list' visualization for these events: grouping,
> individual names, with a good interface to query details if needed. I.e. it should
> be possible to browse and discover events relevant to the CPU the tool is
> executing on.
I suppose we could change perf list to give the stem names as section headers
to make the long list a bit more readable.
Generally you need to have some knowledge of the micro architecture to use
these events. There is no way around that.
-Andi
--
ak@linux•intel.com -- Speaking for myself only
next prev parent reply other threads:[~2015-05-28 15:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 0:02 [PATCH 0/4] perf: Add support for PMU events in JSON format Sukadev Bhattiprolu
2015-05-20 0:02 ` [PATCH 1/4] perf: Add jsmn `jasmine' JSON parser Sukadev Bhattiprolu
2015-05-20 0:02 ` [PATCH 2/4] perf: jevents: Program to convert JSON file to C style file Sukadev Bhattiprolu
2015-05-22 14:56 ` Jiri Olsa
2015-05-22 15:58 ` Sukadev Bhattiprolu
2015-05-22 17:33 ` Jiri Olsa
2015-05-22 18:01 ` Andi Kleen
2015-05-22 18:09 ` Sukadev Bhattiprolu
2015-05-22 21:28 ` Andi Kleen
2015-05-22 14:56 ` Jiri Olsa
2015-05-22 17:25 ` Sukadev Bhattiprolu
2015-05-27 13:54 ` Namhyung Kim
2015-05-27 14:40 ` Andi Kleen
2015-05-27 14:59 ` Namhyung Kim
2015-05-28 11:52 ` Jiri Olsa
2015-05-28 12:09 ` Ingo Molnar
2015-05-28 13:07 ` Ingo Molnar
2015-05-28 15:39 ` Andi Kleen [this message]
2015-05-29 7:27 ` Ingo Molnar
2015-05-31 16:07 ` Andi Kleen
2015-05-20 0:02 ` [PATCH 3/4] perf: Use pmu_events_map table to create event aliases Sukadev Bhattiprolu
2015-05-20 23:58 ` Andi Kleen
2015-05-21 0:19 ` Sukadev Bhattiprolu
2015-05-21 2:56 ` Andi Kleen
2015-05-21 5:02 ` Sukadev Bhattiprolu
2015-05-21 18:50 ` Andi Kleen
2015-05-20 0:02 ` [PATCH 4/4] perf: Add power8 PMU events in JSON format Sukadev Bhattiprolu
2015-05-27 13:59 ` Namhyung Kim
2015-05-27 14:41 ` Andi Kleen
2015-05-27 15:01 ` Namhyung Kim
2015-05-27 16:24 ` Andi Kleen
2015-05-27 20:24 ` Sukadev Bhattiprolu
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=20150528153911.GO7484@tassilo.jf.intel.com \
--to=ak@linux$(echo .)intel.com \
--cc=acme@kernel$(echo .)org \
--cc=jolsa@redhat$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mingo@kernel$(echo .)org \
--cc=mingo@redhat$(echo .)com \
--cc=mpe@ellerman$(echo .)id.au \
--cc=namhyung@kernel$(echo .)org \
--cc=paulus@samba$(echo .)org \
--cc=sukadev@linux$(echo .)vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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