Re: [perfmon2] updating perf tool

Re: [perfmon2] updating perf tool

[Arun Sharma]

[ bcc: perfmon2-devel, +linux-perf-users ]

On Fri, Feb 11, 2011 at 11:16 AM, Can Hankendi <hankendi@gmail.com> wrote:
> Hi,
>
> I'm using 2.6.38 kernel and trying to run performance tests for individual
> cores on my system. But it seems like current kernel doesn't include the
> patches for perf events. I tried to collect data per core with -A  and also
> -G parameters but I got "Error: unknown switch". Where can I find the latest
> patch for perf tool? How can I update the perf tools so that i can use the
> new capabilities of perf tool?
>

Per CPU collection is:

perf record -C <cpulist> -e <events>

 -Arun

Re: [perfmon2] updating perf tool

[Arun Sharma]

On Fri, Feb 11, 2011 at 12:21 PM, Can Hankendi <hankendi@gmail.com> wrote:
> Thanks for the reply.  I've tried perf record -C 0 -e cycles sleep 1 but i
> received an error: Couldn't record kernel reference relocation symbol. Is it
> possible to create per core report by using perf stat -C 0,1 so that I can
> have individual stats for each core?

# ./perf stat -e cycles -A -a -- sleep 1

 Performance counter stats for 'sleep 1':

CPU0         2,145,862,116 cycles
CPU1         2,146,131,064 cycles
CPU2         2,146,021,047 cycles
[...]

and you can grep out only the CPUs you're looking for.

If you're looking to do something more complicated that really
requires hacking up a script, I wrapped the perf_event_open syscall in
python via swig.

sys.py --cpulist

may be interesting.

http://perfmon2.git.sourceforge.net/git/gitweb.cgi?p=perfmon2/libpfm4;a=blob;f=python/sys.py;h=e3a44f24174b979694e2588592f759010b77621e;hb=f70e032b5b69cf5aa6f7e0da746b1817c64341e9

 -Arun

Re: [perfmon2] updating perf tool

[Arnaldo Carvalho de Melo]

Em Fri, Feb 11, 2011 at 12:31:11PM -0800, Arun Sharma escreveu:
> On Fri, Feb 11, 2011 at 12:21 PM, Can Hankendi <hankendi@gmail.com> wrote:
> > Thanks for the reply.  I've tried perf record -C 0 -e cycles sleep 1 but i
> > received an error: Couldn't record kernel reference relocation symbol. Is it
> > possible to create per core report by using perf stat -C 0,1 so that I can
> > have individual stats for each core?
> 
> # ./perf stat -e cycles -A -a -- sleep 1
> 
>  Performance counter stats for 'sleep 1':
> 
> CPU0         2,145,862,116 cycles
> CPU1         2,146,131,064 cycles
> CPU2         2,146,021,047 cycles
> [...]
> 
> and you can grep out only the CPUs you're looking for.
> 
> If you're looking to do something more complicated that really
> requires hacking up a script, I wrapped the perf_event_open syscall in
> python via swig.
> 
> sys.py --cpulist
> 
> may be interesting.
> 
> http://perfmon2.git.sourceforge.net/git/gitweb.cgi?p=perfmon2/libpfm4;a=blob;f=python/sys.py;h=e3a44f24174b979694e2588592f759010b77621e;hb=f70e032b5b69cf5aa6f7e0da746b1817c64341e9

Interesting, have you seen the python binding in tip/perf/core?

- Arnaldo

Re: [perfmon2] updating perf tool

[Arun Sharma]

On Mon, Feb 14, 2011 at 11:44 AM, Arnaldo Carvalho de Melo
<acme@ghostprotocols.net> wrote:
>>
>> http://perfmon2.git.sourceforge.net/git/gitweb.cgi?p=perfmon2/libpfm4;a=blob;f=python/sys.py;h=e3a44f24174b979694e2588592f759010b77621e;hb=f70e032b5b69cf5aa6f7e0da746b1817c64341e9
>
> Interesting, have you seen the python binding in tip/perf/core?

My understanding of the stuff under scripts/python is that it links in
a python interpreter into perf and allows the user to write scripts to
filter the data coming in from the kernel.

The scripts I wrote a couple of years ago knew nothing about perf, the
user space tool and wrapped the syscall directly. Sample use case:
parse the hardware topology of a machine, understand how many NUMA
nodes/memory controllers there are in the system and print the
percentage of the memory bandwidth being used on each controller.

Potentially, perf itself could be structured as a set of shared
libraries, which are then glued together using a scripting language.
That may be the wrong trade-off for many users, who value simplicity
and efficiency of a tool written in C over scriptability. But such a
design could make activities such as parsing perf.data in a python
script essentially free.

 -Arun

Re: [perfmon2] updating perf tool

[Arnaldo Carvalho de Melo]

Em Mon, Feb 14, 2011 at 12:08:28PM -0800, Arun Sharma escreveu:
> On Mon, Feb 14, 2011 at 11:44 AM, Arnaldo Carvalho de Melo wrote

> >> http://perfmon2.git.sourceforge.net/git/gitweb.cgi?p=perfmon2/libpfm4;a=blob;f=python/sys.py;h=e3a44f24174b979694e2588592f759010b77621e;hb=f70e032b5b69cf5aa6f7e0da746b1817c64341e9

> > Interesting, have you seen the python binding in tip/perf/core?

> My understanding of the stuff under scripts/python is that it links in
> a python interpreter into perf and allows the user to write scripts to
> filter the data coming in from the kernel.

That is not what I'm talking about :-)

I'm talking about:

http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commitdiff;h=877108e42b1b9ba64857c4030cf356ecc120fd18

<quote cset log>

perf tools: Initial python binding

Sun, 30 Jan 2011 13:37:38 +0000 (11:37 -0200)

First clarifying that this kind of binding is not a replacement or an
equivalent to the 'perf script' way of using python with perf.

The 'perf script' way is to process events and look at a given script
for some python function that matches the events to pass each event for
processing.

This is a python module, i.e. everything is driven from the python
script, that merely uses "import perf" or "from perf import".

perf script is focused on tracepoints, this binding is focused on profiling as
an initial target. More work is needed to make available tracepoint specific
variables as event variables accessible via this binding.

</>
 
> The scripts I wrote a couple of years ago knew nothing about perf, the
> user space tool and wrapped the syscall directly. Sample use case:
> parse the hardware topology of a machine, understand how many NUMA
> nodes/memory controllers there are in the system and print the
> percentage of the memory bandwidth being used on each controller.

That is really cool, I should use something like that in another tool
that does topology parsing, GUI representation of it:

https://www.osadl.org/Single-View.111+M52212cb1379.0.html
http://userweb.kernel.org/~acme/tuna/screenshots/4socket6core.png
 
> Potentially, perf itself could be structured as a set of shared
> libraries, which are then glued together using a scripting language.

That is what I'm talking about, see above commit.

> That may be the wrong trade-off for many users, who value simplicity
> and efficiency of a tool written in C over scriptability. But such a
> design could make activities such as parsing perf.data in a python
> script essentially free.

Agreed :-)

- Arnaldo

Re: [perfmon2] updating perf tool

[Arun Sharma]

On Mon, Feb 14, 2011 at 12:48 PM, Arnaldo Carvalho de Melo
<acme@ghostprotocols.net> wrote:

>> Potentially, perf itself could be structured as a set of shared
>> libraries, which are then glued together using a scripting language.
>
> That is what I'm talking about, see above commit.
>

Sorry, I misunderstood. Looks like a step in the right direction!

 -Arun

Re: [perfmon2] updating perf tool

[Arnaldo Carvalho de Melo]

Em Mon, Feb 14, 2011 at 02:04:35PM -0800, Arun Sharma escreveu:
> On Mon, Feb 14, 2011 at 12:48 PM, Arnaldo Carvalho de Melo wrote

> >> Potentially, perf itself could be structured as a set of shared
> >> libraries, which are then glued together using a scripting language.

> > That is what I'm talking about, see above commit.

> Sorry, I misunderstood. Looks like a step in the right direction!

:-)

I really need to look at the efforts you made in this direction,
experimentation, as in the --timehist case, is badly needed till we get
a good set of features for easing more widespread and innovative use of
this infrastructure.

On another use case, take the 'perf script' case: as I user I keep doing:

perf probe -L somefunction
perf probe falias=somefunction:line alias=long->variable->expression
perf record -e probe:f*
perf script -g python
perf script -s perf-script.py

rinse, repeat, using the shell script history to speed things up, surely
this can be shortened, as --timehist can be detected by report as
present in a perf.data file, etc.

Finding out use cases fast paths is the end goal, I think.

- Arnaldo

Re: [perfmon2] updating perf tool

[Arun Sharma]

On Mon, Feb 14, 2011 at 5:24 PM, Arnaldo Carvalho de Melo
<acme@ghostprotocols.net> wrote:

> I really need to look at the efforts you made in this direction,
> experimentation, as in the --timehist case, is badly needed till we get
> a good set of features for easing more widespread and innovative use of
> this infrastructure.

If you're trying to marry python, cpuid, hardware topology detection
and linux syscalls not wrapped in python (yet), these projects might
also be interesting:

http://code.google.com/p/module-linux/
http://code.google.com/p/pycpuid/

Specifically:

http://code.google.com/p/pycpuid/source/browse/trunk/test/hwtopo.py

 -Arun