From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: Stephane Eranian <eranian@google.com>,
Ingo Molnar <mingo@elte.hu>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
linux-kernel@vger.kernel.org, Lin Ming <ming.m.lin@intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
eranian@gmail.com, Arun Sharma <asharma@fb.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [generalized cache events] Re: [PATCH 1/1] perf tools: Add missing user space support for config1/config2
Date: Tue, 26 Apr 2011 11:25:57 +0200 [thread overview]
Message-ID: <1303809957.20212.218.camel@twins> (raw)
In-Reply-To: <20110422165120.GA16607@tassilo.jf.intel.com>
On Fri, 2011-04-22 at 09:51 -0700, Andi Kleen wrote:
>
> Micro architectures are so different. I suspect a "generic" definition would
> need to be so vague as to be useless.
>
> This in general seems to be the problem of the current cache events.
>
> Overall for any interesting analysis you need to go CPU specific.
> Abstracted performance analysis is a contradiction in terms.
It might help if you'd talk to your own research department before
making statements like that, they make you look silly.
Intel research has shown that you don't actually need exact definitions
as a side effect of applying machine learning principles in order to
provide machine aided optimizing (ie. clippy style guides for vtune).
They create simple micro-kernels (not our kind of kernels, but more like
the excellent example Arun provided) that trigger a pathological case
and a perfect counter-case and run it over _all_ possible events and do
correlation analysis.
The explicit example given was branch misses on an atom, and they found
(to nobody's great surprise) BR_INST_RETIRED.MISPRED to be the best
correlating event. But that's not the important part.
The important part is that all it needs is a strong correlation, and it
could even be a combination of events, it would just make the analysis a
bit more complex.
Anyway, given a sufficient large set of these pathological cases, you
can train a neural net for your target hardware and then reverse the
situation, run it over an unknown program and have it create suggestions
-> yay clippy!
So given a set of pathological cases and hardware with decent PMU
coverage you can train this thing and get useful results. Exact event
definitions be damned -- it doesn't care.
http://sites.google.com/site/fhpm2010/program/baugh_fhpm2010.pptx?attredirects=0
next prev parent reply other threads:[~2011-04-26 9:26 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-22 8:47 [PATCH 1/1] perf tools: Add missing user space support for config1/config2 Stephane Eranian
2011-04-22 9:23 ` Ingo Molnar
2011-04-22 9:41 ` Stephane Eranian
2011-04-22 10:52 ` [generalized cache events] " Ingo Molnar
2011-04-22 12:04 ` Stephane Eranian
2011-04-22 13:18 ` Ingo Molnar
2011-04-22 20:31 ` Stephane Eranian
2011-04-22 20:47 ` Ingo Molnar
2011-04-23 12:13 ` Stephane Eranian
2011-04-23 12:49 ` Ingo Molnar
2011-04-22 21:03 ` Ingo Molnar
2011-04-23 12:27 ` Stephane Eranian
2011-04-22 16:51 ` Andi Kleen
2011-04-22 19:57 ` Ingo Molnar
2011-04-26 9:25 ` Peter Zijlstra [this message]
2011-04-22 16:50 ` arun
2011-04-22 17:00 ` Andi Kleen
2011-04-22 20:30 ` Ingo Molnar
2011-04-22 20:32 ` Ingo Molnar
2011-04-23 0:03 ` Andi Kleen
2011-04-23 7:50 ` Peter Zijlstra
2011-04-23 12:06 ` Stephane Eranian
2011-04-23 12:36 ` Ingo Molnar
2011-04-23 13:16 ` Peter Zijlstra
2011-04-25 18:48 ` Stephane Eranian
2011-04-25 19:40 ` Andi Kleen
2011-04-25 19:55 ` Ingo Molnar
2011-04-24 2:15 ` Andi Kleen
2011-04-24 2:19 ` Andi Kleen
2011-04-25 17:41 ` Ingo Molnar
2011-04-25 18:00 ` Dehao Chen
[not found] ` <BANLkTiks31-pMJe4zCKrppsrA1d6KanJFA@mail.gmail.com>
2011-04-25 18:05 ` Ingo Molnar
2011-04-25 18:39 ` Stephane Eranian
2011-04-25 19:45 ` Ingo Molnar
2011-04-23 8:02 ` Ingo Molnar
2011-04-23 20:14 ` [PATCH] perf events: Add stalled cycles generic event - PERF_COUNT_HW_STALLED_CYCLES Ingo Molnar
2011-04-24 6:16 ` Arun Sharma
2011-04-25 17:37 ` Ingo Molnar
2011-04-26 9:25 ` Peter Zijlstra
2011-04-26 14:00 ` Ingo Molnar
2011-04-27 11:11 ` Ingo Molnar
2011-04-27 14:47 ` Arun Sharma
2011-04-27 15:48 ` Ingo Molnar
2011-04-27 16:27 ` Ingo Molnar
2011-04-27 19:05 ` Arun Sharma
2011-04-27 19:03 ` Arun Sharma
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=1303809957.20212.218.camel@twins \
--to=peterz@infradead.org \
--cc=acme@infradead.org \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=asharma@fb.com \
--cc=eranian@gmail.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--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.