* [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
@ 2012-06-28 16:00 Feng Tang
2012-06-28 16:12 ` Peter Zijlstra
2012-07-03 7:36 ` Michael Ellerman
0 siblings, 2 replies; 18+ messages in thread
From: Feng Tang @ 2012-06-28 16:00 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Peter Zijlstra, Ingo Molnar, linux-kernel
Cc: x86, Stephane Eranian, Andi Kleen, Feng Tang
From: Andi Kleen <ak@linux.intel.com>
Add support for reporting PEBS records in a raw format that can
be then parsed by perf script.
This is roughly similar to the existing AMD IBS support.
This is mainly for advanced users and to experiment with
new usages. Widespread PEBS usages are expected to get higher
level interfaces over time, like the existing "precise ip" support.
[Small fix of adding "data.raw = &raw;", thanks to Andi, with this
patch I can test my perf script with pebs samples. - Feng]
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Feng Tang <feng.tang@intel.com>
---
arch/x86/kernel/cpu/perf_event_intel_ds.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 026373e..04d3ba9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -552,6 +552,7 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
struct pebs_record_core *pebs = __pebs;
struct perf_sample_data data;
struct pt_regs regs;
+ struct perf_raw_record raw;
if (!intel_pmu_save_and_restart(event))
return;
@@ -578,6 +579,12 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
else
regs.flags &= ~PERF_EFLAGS_EXACT;
+ if (event->attr.sample_type & PERF_SAMPLE_RAW) {
+ raw.size = x86_pmu.pebs_record_size;
+ raw.data = __pebs;
+ data.raw = &raw;
+ }
+
if (has_branch_stack(event))
data.br_stack = &cpuc->lbr_stack;
--
1.7.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:00 [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format Feng Tang
@ 2012-06-28 16:12 ` Peter Zijlstra
2012-06-28 16:15 ` Stephane Eranian
2012-06-28 18:20 ` Andi Kleen
2012-07-03 7:36 ` Michael Ellerman
1 sibling, 2 replies; 18+ messages in thread
From: Peter Zijlstra @ 2012-06-28 16:12 UTC (permalink / raw)
To: Feng Tang
Cc: Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel, x86,
Stephane Eranian, Andi Kleen
On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> Add support for reporting PEBS records in a raw format that can
> be then parsed by perf script.
>
> This is roughly similar to the existing AMD IBS support.
>
> This is mainly for advanced users and to experiment with
> new usages. Widespread PEBS usages are expected to get higher
> level interfaces over time, like the existing "precise ip" support.
>
> [Small fix of adding "data.raw = &raw;", thanks to Andi, with this
> patch I can test my perf script with pebs samples. - Feng]
>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> Signed-off-by: Feng Tang <feng.tang@intel.com>
Not without a useful userspace part. Preferably not a script.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:12 ` Peter Zijlstra
@ 2012-06-28 16:15 ` Stephane Eranian
2012-06-28 16:19 ` Peter Zijlstra
2012-06-28 18:20 ` Andi Kleen
1 sibling, 1 reply; 18+ messages in thread
From: Stephane Eranian @ 2012-06-28 16:15 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Andi Kleen
I will cover some useful use cases with my PEBS-LL patchset + perf support.
On Thu, Jun 28, 2012 at 6:12 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
>> From: Andi Kleen <ak@linux.intel.com>
>>
>> Add support for reporting PEBS records in a raw format that can
>> be then parsed by perf script.
>>
>> This is roughly similar to the existing AMD IBS support.
>>
>> This is mainly for advanced users and to experiment with
>> new usages. Widespread PEBS usages are expected to get higher
>> level interfaces over time, like the existing "precise ip" support.
>>
>> [Small fix of adding "data.raw = &raw;", thanks to Andi, with this
>> patch I can test my perf script with pebs samples. - Feng]
>>
>> Signed-off-by: Andi Kleen <ak@linux.intel.com>
>> Signed-off-by: Feng Tang <feng.tang@intel.com>
>
> Not without a useful userspace part. Preferably not a script.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:15 ` Stephane Eranian
@ 2012-06-28 16:19 ` Peter Zijlstra
2012-06-28 16:27 ` Stephane Eranian
0 siblings, 1 reply; 18+ messages in thread
From: Peter Zijlstra @ 2012-06-28 16:19 UTC (permalink / raw)
To: Stephane Eranian
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Andi Kleen
On Thu, 2012-06-28 at 18:15 +0200, Stephane Eranian wrote:
> I will cover some useful use cases with my PEBS-LL patchset + perf
> support.
>
OK, I'll wait for those then.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:19 ` Peter Zijlstra
@ 2012-06-28 16:27 ` Stephane Eranian
2012-06-28 16:29 ` Peter Zijlstra
2012-06-28 18:26 ` Andi Kleen
0 siblings, 2 replies; 18+ messages in thread
From: Stephane Eranian @ 2012-06-28 16:27 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Andi Kleen
My patchset does not cover the general PEBS case (not LL). However, I
think we can leverage
the machine state captured by PEBS by adding a simple patch on top of
Jiri's sample regs
patchset. I have experimented with that last week. One interesting
measurement you can make
on SNB once you have that is : value profiling. That means sampling
the values of function
arguments. I think we can fit this into perf report.
My problem with the script approach is that you may end up
re-inventing a lot of the infrastructure
already in perf in terms of histograming and sorting. I think scripts
are good for dumping
the raw data or very simply analysis. Now I recognize that they are
handy to implement
mahcine specific decoding of the samples.
On Thu, Jun 28, 2012 at 6:19 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2012-06-28 at 18:15 +0200, Stephane Eranian wrote:
>> I will cover some useful use cases with my PEBS-LL patchset + perf
>> support.
>>
> OK, I'll wait for those then.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:27 ` Stephane Eranian
@ 2012-06-28 16:29 ` Peter Zijlstra
2012-06-28 18:26 ` Andi Kleen
1 sibling, 0 replies; 18+ messages in thread
From: Peter Zijlstra @ 2012-06-28 16:29 UTC (permalink / raw)
To: Stephane Eranian
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Andi Kleen
On Thu, 2012-06-28 at 18:27 +0200, Stephane Eranian wrote:
>
> My problem with the script approach is that you may end up
> re-inventing a lot of the infrastructure
> already in perf in terms of histograming and sorting. I think scripts
> are good for dumping
> the raw data or very simply analysis. Now I recognize that they are
> handy to implement
> mahcine specific decoding of the samples.
Yeah, I'm no fan of all that script nonsense either. If its worth doing
its worth doing properly.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:12 ` Peter Zijlstra
2012-06-28 16:15 ` Stephane Eranian
@ 2012-06-28 18:20 ` Andi Kleen
2012-06-28 20:51 ` Peter Zijlstra
2012-06-29 12:49 ` Ingo Molnar
1 sibling, 2 replies; 18+ messages in thread
From: Andi Kleen @ 2012-06-28 18:20 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Stephane Eranian
> Not without a useful userspace part.
http://permalink.gmane.org/gmane.linux.kernel/1319962
> Preferably not a script.
You don't need to prefer it.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:27 ` Stephane Eranian
2012-06-28 16:29 ` Peter Zijlstra
@ 2012-06-28 18:26 ` Andi Kleen
1 sibling, 0 replies; 18+ messages in thread
From: Andi Kleen @ 2012-06-28 18:26 UTC (permalink / raw)
To: Stephane Eranian
Cc: Peter Zijlstra, Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar,
linux-kernel, x86
> My problem with the script approach is that you may end up
> re-inventing a lot of the infrastructure
> already in perf in terms of histograming and sorting. I think scripts
All built into modern scripting languages. Only in C you have to reinvent
it.
> are good for dumping
> the raw data or very simply analysis. Now I recognize that they are
> handy to implement
> mahcine specific decoding of the samples.
The main use case is really custom analysis, so that people can do
whatever custom data mining they want.
But I expect once you get users engaged with a simple interface
you'll get much more.
But even the existing script is quite useful and gives you
a lot of information. It's also very easy to extend to everyone
knowing SQLite.
Can you do all these things the simple script does?
-Andi
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 18:20 ` Andi Kleen
@ 2012-06-28 20:51 ` Peter Zijlstra
2012-06-29 1:32 ` Feng Tang
2012-06-29 12:49 ` Ingo Molnar
1 sibling, 1 reply; 18+ messages in thread
From: Peter Zijlstra @ 2012-06-28 20:51 UTC (permalink / raw)
To: Andi Kleen
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Stephane Eranian
On Thu, 2012-06-28 at 11:20 -0700, Andi Kleen wrote:
> > Not without a useful userspace part.
>
> http://permalink.gmane.org/gmane.linux.kernel/1319962
>
> > Preferably not a script.
>
> You don't need to prefer it.
+# will be very time consuming (about 10+ minutes for 10000 samples) if the
Muhahaha... I'll wait for something useful.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 20:51 ` Peter Zijlstra
@ 2012-06-29 1:32 ` Feng Tang
2012-06-29 3:35 ` Andi Kleen
0 siblings, 1 reply; 18+ messages in thread
From: Feng Tang @ 2012-06-29 1:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andi Kleen, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Stephane Eranian
On Thu, 28 Jun 2012 22:51:37 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2012-06-28 at 11:20 -0700, Andi Kleen wrote:
> > > Not without a useful userspace part.
> >
> > http://permalink.gmane.org/gmane.linux.kernel/1319962
> >
> > > Preferably not a script.
> >
> > You don't need to prefer it.
>
> +# will be very time consuming (about 10+ minutes for 10000 samples) if the
>
> Muhahaha... I'll wait for something useful.
Yeah, that number scared me too when I first saw it, as the time will make
the script totally useless. Then after migrating to the RAM based database
file, the database handling time could be cut down to 1 second.
I guess the sqlite itself realize the shortcoming too, it also provide a
native way to use in-memory database by specifying ":memory":
con = sqlite3.connect(":memory:")
Thanks,
Feng
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-29 1:32 ` Feng Tang
@ 2012-06-29 3:35 ` Andi Kleen
0 siblings, 0 replies; 18+ messages in thread
From: Andi Kleen @ 2012-06-29 3:35 UTC (permalink / raw)
To: Feng Tang
Cc: Peter Zijlstra, Arnaldo Carvalho de Melo, Ingo Molnar,
linux-kernel, x86, Stephane Eranian
> Yeah, that number scared me too when I first saw it, as the time will make
> the script totally useless. Then after migrating to the RAM based database
> file, the database handling time could be cut down to 1 second.
The problem is just that sqlite does a fdatasync for every insert.
Just need to figure out how to tell it to stop doing that.
Shouldn't be too hard ...
But yes /dev/shm should work well enough for now.
>
> I guess the sqlite itself realize the shortcoming too, it also provide a
> native way to use in-memory database by specifying ":memory":
> con = sqlite3.connect(":memory:")
I think it's better to have a file on disk, then you can easily query
more properties just from the command line.
I can see all kinds of interesting data mining on the events
to be enabled by this. They have all the register values and various
other information.
For example if you look for string operations you could do
a histogram over the ECX values and so do a histogram of
memcpy/memset sizes.
[Would be easier if perf could pass in the assembler opcode,
but could be done without)
Or when sampling spinlocks look at the addresses.
Or lots of other things people could imagine.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 18:20 ` Andi Kleen
2012-06-28 20:51 ` Peter Zijlstra
@ 2012-06-29 12:49 ` Ingo Molnar
1 sibling, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2012-06-29 12:49 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar,
linux-kernel, x86, Stephane Eranian
* Andi Kleen <ak@linux.intel.com> wrote:
> > Not without a useful userspace part.
>
> http://permalink.gmane.org/gmane.linux.kernel/1319962
>
> > Preferably not a script.
>
> You don't need to prefer it.
Kernel development 101, Chapter 1.:
" If you want your patches to be applied by the maintainer
then you'll have to address the maintainer's review
requests. "
Thanks,
Ingo
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-06-28 16:00 [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format Feng Tang
2012-06-28 16:12 ` Peter Zijlstra
@ 2012-07-03 7:36 ` Michael Ellerman
2012-07-03 9:15 ` Peter Zijlstra
1 sibling, 1 reply; 18+ messages in thread
From: Michael Ellerman @ 2012-07-03 7:36 UTC (permalink / raw)
To: Feng Tang
Cc: Arnaldo Carvalho de Melo, Peter Zijlstra, Ingo Molnar,
linux-kernel, x86, Stephane Eranian, Andi Kleen
On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> Add support for reporting PEBS records in a raw format that can
> be then parsed by perf script.
>
> This is roughly similar to the existing AMD IBS support.
>
> This is mainly for advanced users and to experiment with
> new usages. Widespread PEBS usages are expected to get higher
> level interfaces over time, like the existing "precise ip" support.
Hi folks,
Pardon if I slightly hijack this thread, but we'd like to do something
similar to this on powerpc.
I've been telling people not to use PERF_SAMPLE_RAW because it provides
no way for the consumer to know what data they're getting, and it's not
extensible in any way.
So is shovelling things out using PERF_SAMPLE_RAW generally acceptable
for "advanced usage" scenarios?
cheers
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-07-03 7:36 ` Michael Ellerman
@ 2012-07-03 9:15 ` Peter Zijlstra
2012-07-04 8:07 ` Michael Ellerman
0 siblings, 1 reply; 18+ messages in thread
From: Peter Zijlstra @ 2012-07-03 9:15 UTC (permalink / raw)
To: Michael Ellerman
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Stephane Eranian, Andi Kleen
On Tue, 2012-07-03 at 17:36 +1000, Michael Ellerman wrote:
> On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
> > From: Andi Kleen <ak@linux.intel.com>
> >
> > Add support for reporting PEBS records in a raw format that can
> > be then parsed by perf script.
> >
> > This is roughly similar to the existing AMD IBS support.
> >
> > This is mainly for advanced users and to experiment with
> > new usages. Widespread PEBS usages are expected to get higher
> > level interfaces over time, like the existing "precise ip" support.
>
> Hi folks,
>
> Pardon if I slightly hijack this thread, but we'd like to do something
> similar to this on powerpc.
Do expand. What does exact information does it provide?
> I've been telling people not to use PERF_SAMPLE_RAW because it provides
> no way for the consumer to know what data they're getting, and it's not
> extensible in any way.
>
> So is shovelling things out using PERF_SAMPLE_RAW generally acceptable
> for "advanced usage" scenarios?
No.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-07-03 9:15 ` Peter Zijlstra
@ 2012-07-04 8:07 ` Michael Ellerman
2012-07-04 9:13 ` Peter Zijlstra
0 siblings, 1 reply; 18+ messages in thread
From: Michael Ellerman @ 2012-07-04 8:07 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Stephane Eranian, Andi Kleen
On Tue, 2012-07-03 at 11:15 +0200, Peter Zijlstra wrote:
> On Tue, 2012-07-03 at 17:36 +1000, Michael Ellerman wrote:
> > On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
> > > From: Andi Kleen <ak@linux.intel.com>
> > >
> > > Add support for reporting PEBS records in a raw format that can
> > > be then parsed by perf script.
> > >
> > > This is roughly similar to the existing AMD IBS support.
> > >
> > > This is mainly for advanced users and to experiment with
> > > new usages. Widespread PEBS usages are expected to get higher
> > > level interfaces over time, like the existing "precise ip" support.
> >
> > Hi folks,
> >
> > Pardon if I slightly hijack this thread, but we'd like to do something
> > similar to this on powerpc.
>
> Do expand. What does exact information does it provide?
Basically we have three registers which provide various information about
the instruction which caused an event to overflow.
The first reports the address of the instruction, the second the data
address associated with the instruction, and the third reports "other
stuff".
We use the first for SAMPLE_IP, and the second for SAMPLE_ADDR, but
currently we have no way of spitting out the third register.
There's a whole bunch of info in there. I think the most interesting are
stuff like whether and where in the pipeline the instruction stalled, or
where a load was serviced from. I'm not sure to be honest, so I've asked
the HW guys what they're most interested in.
So I can imagine us coming up with a generic sample type for "sample
other info at event overflow", but I'm struggling to see how we'd make
the content of the sample non architecture specific, or even processor
version specific.
> > I've been telling people not to use PERF_SAMPLE_RAW because it provides
> > no way for the consumer to know what data they're getting, and it's not
> > extensible in any way.
> >
> > So is shovelling things out using PERF_SAMPLE_RAW generally acceptable
> > for "advanced usage" scenarios?
>
> No.
OK good, at least I was right about that :)
cheers
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-07-04 8:07 ` Michael Ellerman
@ 2012-07-04 9:13 ` Peter Zijlstra
2012-07-05 15:57 ` Stephane Eranian
0 siblings, 1 reply; 18+ messages in thread
From: Peter Zijlstra @ 2012-07-04 9:13 UTC (permalink / raw)
To: Michael Ellerman
Cc: Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar, linux-kernel,
x86, Stephane Eranian, Andi Kleen, Robert Richter
On Wed, 2012-07-04 at 18:07 +1000, Michael Ellerman wrote:
> Basically we have three registers which provide various information about
> the instruction which caused an event to overflow.
>
> The first reports the address of the instruction, the second the data
> address associated with the instruction, and the third reports "other
> stuff".
>
> We use the first for SAMPLE_IP, and the second for SAMPLE_ADDR, but
> currently we have no way of spitting out the third register.
>
> There's a whole bunch of info in there. I think the most interesting are
> stuff like whether and where in the pipeline the instruction stalled, or
> where a load was serviced from. I'm not sure to be honest, so I've asked
> the HW guys what they're most interested in.
>
> So I can imagine us coming up with a generic sample type for "sample
> other info at event overflow", but I'm struggling to see how we'd make
> the content of the sample non architecture specific, or even processor
> version specific.
Right so we're working on a data-source like thing, the last attempt at
adding something like that is in this thread:
http://marc.info/?l=linux-kernel&m=130987553915170&w=2
http://marc.info/?l=linux-kernel&m=131000375226044
I think Stephane is currently trying to revive that, although he hasn't
posted yet. Please have a look if that captures the possible PPC states
as well. Stephane could you share your current stuff so Michael can have
a look?
Not quite sure what to do for your pipeline stage thing, I'm not sure
I've seen that elsewhere.
Anyway, yes PERF_SAMPLE_RAW is the 'other info at overflow' which is
specific to the current cpu and phase of moon type field, and it does
get (ab)used in various places, but I still cringe every time I see it
used.
The problem with that thing is that it gives people the data they need
for their special tools and thus removes them from the incentive pool to
help create more generic,useful tools.
For AMD IBS we've given in since that thing is completely weird, IIRC
Robert was going to grow perf-ibs to record and report the data it
captures so we've at least got a useful open-source tool for it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-07-04 9:13 ` Peter Zijlstra
@ 2012-07-05 15:57 ` Stephane Eranian
2012-07-07 7:27 ` Michael Ellerman
0 siblings, 1 reply; 18+ messages in thread
From: Stephane Eranian @ 2012-07-05 15:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Ellerman, Feng Tang, Arnaldo Carvalho de Melo,
Ingo Molnar, linux-kernel, x86, Andi Kleen, Robert Richter
On Wed, Jul 4, 2012 at 11:13 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2012-07-04 at 18:07 +1000, Michael Ellerman wrote:
>> Basically we have three registers which provide various information about
>> the instruction which caused an event to overflow.
>>
>> The first reports the address of the instruction, the second the data
>> address associated with the instruction, and the third reports "other
>> stuff".
>>
>> We use the first for SAMPLE_IP, and the second for SAMPLE_ADDR, but
>> currently we have no way of spitting out the third register.
>>
>> There's a whole bunch of info in there. I think the most interesting are
>> stuff like whether and where in the pipeline the instruction stalled, or
>> where a load was serviced from. I'm not sure to be honest, so I've asked
>> the HW guys what they're most interested in.
>>
>> So I can imagine us coming up with a generic sample type for "sample
>> other info at event overflow", but I'm struggling to see how we'd make
>> the content of the sample non architecture specific, or even processor
>> version specific.
>
> Right so we're working on a data-source like thing, the last attempt at
> adding something like that is in this thread:
>
> http://marc.info/?l=linux-kernel&m=130987553915170&w=2
> http://marc.info/?l=linux-kernel&m=131000375226044
>
> I think Stephane is currently trying to revive that, although he hasn't
> posted yet. Please have a look if that captures the possible PPC states
> as well. Stephane could you share your current stuff so Michael can have
> a look?
>
I am currently on vacation and with limited internet access.
But yes, the PEBS-LL patchset I have been working on
does abstract PEBS-LL and offers an abstracted data source
field. It uses:
PERF_SAMPLE_IP: for instr address
PERF_SAMPLE_ADDR: for the data address
It introduces:
PERF_SAMPLE_LATENCY: to capture the access latency
PERF_SAMPLE_DSRC: to encode the data source.
That latter value is a structured bitmask which covers:
- type of access (load, store, prefetch, instr)
- mem level: hit or miss in L1, LFB, L2, L3, LOC_RAM, REM_RAM, uncached, IO
- snoop access: hit, miss, none
- TLB access: hit or miss in L1, L2, HW walker, OS fault
Hopefully those are generic enough to cover all possible cases across
architectures. PPC would be a good test case.
Note that multiple bits per category may be set in case the HW cannot
disambiguate like this is the case on with PEBS-LL sometimes.
>
> Not quite sure what to do for your pipeline stage thing, I'm not sure
> I've seen that elsewhere.
>
>
> Anyway, yes PERF_SAMPLE_RAW is the 'other info at overflow' which is
> specific to the current cpu and phase of moon type field, and it does
> get (ab)used in various places, but I still cringe every time I see it
> used.
>
> The problem with that thing is that it gives people the data they need
> for their special tools and thus removes them from the incentive pool to
> help create more generic,useful tools.
>
> For AMD IBS we've given in since that thing is completely weird, IIRC
> Robert was going to grow perf-ibs to record and report the data it
> captures so we've at least got a useful open-source tool for it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
2012-07-05 15:57 ` Stephane Eranian
@ 2012-07-07 7:27 ` Michael Ellerman
0 siblings, 0 replies; 18+ messages in thread
From: Michael Ellerman @ 2012-07-07 7:27 UTC (permalink / raw)
To: Stephane Eranian
Cc: Peter Zijlstra, Feng Tang, Arnaldo Carvalho de Melo, Ingo Molnar,
linux-kernel, x86, Andi Kleen, Robert Richter
On Thu, 2012-07-05 at 17:57 +0200, Stephane Eranian wrote:
> On Wed, Jul 4, 2012 at 11:13 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > I think Stephane is currently trying to revive that, although he hasn't
> > posted yet. Please have a look if that captures the possible PPC states
> > as well. Stephane could you share your current stuff so Michael can have
> > a look?
> I am currently on vacation and with limited internet access.
No stress, I am currently busy doing other things :)
> But yes, the PEBS-LL patchset I have been working on
> does abstract PEBS-LL and offers an abstracted data source
> field. It uses:
> PERF_SAMPLE_IP: for instr address
> PERF_SAMPLE_ADDR: for the data address
>
> It introduces:
> PERF_SAMPLE_LATENCY: to capture the access latency
> PERF_SAMPLE_DSRC: to encode the data source.
>
> That latter value is a structured bitmask which covers:
> - type of access (load, store, prefetch, instr)
> - mem level: hit or miss in L1, LFB, L2, L3, LOC_RAM, REM_RAM, uncached, IO
> - snoop access: hit, miss, none
> - TLB access: hit or miss in L1, L2, HW walker, OS fault
>
> Hopefully those are generic enough to cover all possible cases across
> architectures. PPC would be a good test case.
> Note that multiple bits per category may be set in case the HW cannot
> disambiguate like this is the case on with PEBS-LL sometimes.
OK that sounds promising. And I like that it's a bitmask.
>From a preliminary look I think the list you have above will cover most
of the information we can report. And we should have some bits left over
for extensibility.
cheers
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2012-07-07 7:27 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-28 16:00 [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format Feng Tang
2012-06-28 16:12 ` Peter Zijlstra
2012-06-28 16:15 ` Stephane Eranian
2012-06-28 16:19 ` Peter Zijlstra
2012-06-28 16:27 ` Stephane Eranian
2012-06-28 16:29 ` Peter Zijlstra
2012-06-28 18:26 ` Andi Kleen
2012-06-28 18:20 ` Andi Kleen
2012-06-28 20:51 ` Peter Zijlstra
2012-06-29 1:32 ` Feng Tang
2012-06-29 3:35 ` Andi Kleen
2012-06-29 12:49 ` Ingo Molnar
2012-07-03 7:36 ` Michael Ellerman
2012-07-03 9:15 ` Peter Zijlstra
2012-07-04 8:07 ` Michael Ellerman
2012-07-04 9:13 ` Peter Zijlstra
2012-07-05 15:57 ` Stephane Eranian
2012-07-07 7:27 ` Michael Ellerman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).