From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>, Jiri Olsa <jolsa@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
David Carrillo-Cisneros <davidcc@google.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
"Liang, Kan" <kan.liang@intel.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 7/7] perf/annotate: Add branch stack / basic block information
Date: Thu, 8 Sep 2016 20:15:52 +0200 [thread overview]
Message-ID: <20160908181552.GW10153@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CABPqkBRuRtZXNN2Mhck0sph-10-k7w31ZhaUO_fbXHfcwfyAzQ@mail.gmail.com>
On Thu, Sep 08, 2016 at 09:43:53AM -0700, Stephane Eranian wrote:
> I like the idea and yes, branch stack can be used for this, but I have
> a hard time understanding the colored output.
> What is the explanation for the color changes?
In general, or the changes acme made? I can only answer the first.
For code: NORMAL <1%, BLUE otherwise, quickly shows you the code in a
function that's not ran at all. This quickly eliminated a big chunk of
the function I was looking at at the time, since the benchmark in
question simply didn't touch most of it.
For address: NORMAL <1%, RED > 75%, MAGENTA otherwise. Quickly shows the
hottest blocks in a function. The 75% is a random number otherwise. Not
sure if we can do better.
> How do I interpret the percentages in the comments of the assembly:
> -54.50% (p: 42%)
-54.50% is 54.40% of the coverage is leaving here, aka 54.40% take this
branch. p: 42% mean the branch is predicted 42% of the time.
Similarly, +50.46% is a branch target and means that of all the times
this instruction gets executed, 50.46% of those joined at this
instruction.
> Why not have dedicated columns before the assembly with proper column headers?
I found it too noisy, you only want to annotate branch instructions and
branch targets. Adding columns just adds a whole heap of whitespace
(wasted screen-estate) on the left.
Something I did want to look at was attempting to align the # comments,
but I never did bother.
But to each their own I suppose.
prev parent reply other threads:[~2016-09-08 18:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-08 13:30 [RFC][PATCH 0/7] perf: Branch stack annotation and fixes Peter Zijlstra
2016-07-08 13:31 ` [RFC][PATCH 1/7] perf/x86/intel: Rework the large PEBS setup code Peter Zijlstra
2016-07-08 16:36 ` Jiri Olsa
2016-07-08 22:00 ` Peter Zijlstra
2016-07-08 22:25 ` Peter Zijlstra
2016-07-10 9:08 ` Jiri Olsa
2016-07-08 13:31 ` [RFC][PATCH 2/7] perf,x86: Ensure perf_sched_cb_{inc,dec}() is only called from pmu::{add,del}() Peter Zijlstra
2016-07-08 13:31 ` [RFC][PATCH 3/7] perf/x86/intel: DCE intel_pmu_lbr_del() Peter Zijlstra
2016-07-08 13:31 ` [RFC][PATCH 4/7] perf/x86/intel: Remove redundant test from intel_pmu_lbr_add() Peter Zijlstra
2016-07-08 13:31 ` [RFC][PATCH 5/7] perf/x86/intel: Clean up LBR state tracking Peter Zijlstra
2016-07-08 13:31 ` [RFC][PATCH 6/7] perf: Optimize perF_pmu_sched_task() Peter Zijlstra
2016-07-08 13:31 ` [RFC][PATCH 7/7] perf/annotate: Add branch stack / basic block information Peter Zijlstra
2016-07-08 14:55 ` Ingo Molnar
2016-07-08 16:27 ` Peter Zijlstra
2016-07-08 16:36 ` Peter Zijlstra
2016-09-08 16:18 ` Arnaldo Carvalho de Melo
2016-09-08 16:41 ` Peter Zijlstra
2016-09-08 16:51 ` Peter Zijlstra
2016-09-08 17:07 ` Arnaldo Carvalho de Melo
2016-09-08 16:43 ` Stephane Eranian
2016-09-08 16:59 ` Andi Kleen
2016-09-08 17:11 ` Arnaldo Carvalho de Melo
2016-09-09 2:40 ` Jin, Yao
2016-09-08 18:15 ` Peter Zijlstra [this message]
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=20160908181552.GW10153@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=davidcc@google.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=torvalds@linux-foundation.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.