Re: [perfmon2] updating perf tool

[Arnaldo Carvalho de Melo <acme@ghostprotocols.net>]

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