From: Andi Kleen <[email protected]>
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 <[email protected]>
Signed-off-by: Feng Tang <[email protected]>
---
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
On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
> From: Andi Kleen <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Feng Tang <[email protected]>
Not without a useful userspace part. Preferably not a script.
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 <[email protected]> wrote:
> On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
>> From: Andi Kleen <[email protected]>
>>
>> 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 <[email protected]>
>> Signed-off-by: Feng Tang <[email protected]>
>
> Not without a useful userspace part. Preferably not a script.
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.
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 <[email protected]> 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.
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.
> 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
--
[email protected] -- Speaking for myself only
> 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
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.
On Thu, 28 Jun 2012 22:51:37 +0200
Peter Zijlstra <[email protected]> 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
> 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
--
[email protected] -- Speaking for myself only
* Andi Kleen <[email protected]> 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