From: Andi Kleen <ak@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jin Yao <yao.jin@linux.intel.com>,
acme@kernel.org, jolsa@kernel.org, mingo@redhat.com,
alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org,
kan.liang@intel.com, yao.jin@intel.com,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/5] perf/x86/intel: Record branch type
Date: Fri, 7 Apr 2017 10:50:06 -0700 [thread overview]
Message-ID: <20170407175006.GB4021@tassilo.jf.intel.com> (raw)
In-Reply-To: <20170407172024.r66fkp4xkux5blxi@hirez.programming.kicks-ass.net>
> > It's a somewhat common situation with partially JITed code, if you
> > don't have an agent. You can still do a lot of useful things.
>
> Like what? How can you say anything about code you don't have?
For example if you combine the PMU topdown measurement, and see if it's
frontend bound, and then you see it has lots of forward conditionals,
then dynamic basic block reordering will help. If you have lots
of cross page jumps then function reordering will help. etc.
> > We found it useful to have this extra information during workload
> > analysis. Forward conditionals and page crossing jumps
> > are indications of frontend problems.
>
> But you already have the exact same information in {to,from}, why would
> you need to repackage information already contained?
Without this patch, we don't know if it's conditional or something else.
And the kernel already knows this for its filtering, so it can as well
report it.
Right the CROSS_* and forward backward information could be computed
later.
-Andi
next prev parent reply other threads:[~2017-04-07 17:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 10:47 [PATCH v2 0/5] perf report: Show branch type Jin Yao
2017-04-07 10:47 ` [PATCH v2 1/5] perf/core: Define the common branch type classification Jin Yao
2017-04-07 10:47 ` [PATCH v2 2/5] perf/x86/intel: Record branch type Jin Yao
2017-04-07 15:20 ` Peter Zijlstra
2017-04-07 16:48 ` Andi Kleen
2017-04-07 17:20 ` Peter Zijlstra
2017-04-07 17:50 ` Andi Kleen [this message]
2017-04-08 8:46 ` Jin, Yao
2017-04-07 10:47 ` [PATCH v2 3/5] perf record: Create a new option save_type in --branch-filter Jin Yao
2017-04-07 10:47 ` [PATCH v2 4/5] perf report: Show branch type statistics for stdio mode Jin Yao
2017-04-07 10:47 ` [PATCH v2 5/5] perf report: Show branch type in callchain entry Jin Yao
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=20170407175006.GB4021@tassilo.jf.intel.com \
--to=ak@linux.intel.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=yao.jin@intel.com \
--cc=yao.jin@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox