Commit graph

22 commits

Author SHA1 Message Date
Arnaldo Carvalho de Melo ef12a14130 perf buildid-cache: Add new command to manage build-id cache
For now it just has operations to examine a given file, find its
build-id and add or remove it to/from the cache.

Useful, for instance, when adding binaries sent together with a
perf.data file, so that we can add them to the cache and have
the tools find it when resolving symbols.

It'll also manage the size of the cache like 'ccache' does.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1264008525-29025-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-21 08:31:29 +01:00
Arnaldo Carvalho de Melo ba21594cdd perf tools: Cross platform perf.data analysis support
There are still some problems related to loading vmlinux files,
but those are unrelated to the feature implemented in this
patch, so will get fixed in the next patches, but here are some
results:

1. collect perf.data file on a Fedora 12 machine, x86_64, 64-bit
userland

2. transfer it to a Debian Testing machine, PARISC64, 32-bit
userland

  acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | head -5
  74f9930ee94475b6b3238caf3725a50d59cb994b [kernel.kallsyms]
  55fdd56670453ea66c011158c4b9d30179c1d049 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
  41adff63c730890480980d5d8ba513f1c216a858 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/iptable_nat.ko
  90a33def1077bb8e97b8a78546dc96c2de62df46 /lib/modules/2.6.33-rc4-tip+/kernel/net/ipv4/netfilter/nf_nat.ko
  984c7bea90ce1376d5c8e7ef43a781801286e62d /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/tun.ko

  acme@parisc:~/git/linux-2.6-tip$ perf buildid-list | tail -5
  22492f3753c6a67de5c7ccbd6b863390c92c0723 /usr/lib64/libXt.so.6.0.0
  353802bb7e1b895ba43507cc678f951e778e4c6f /usr/lib64/libMagickCore.so.2.0.0
  d10c2897558595efe7be8b0584cf7e6398bc776c /usr/lib64/libfprint.so.0.0.0
  a83ecfb519a788774a84d5ddde633c9ba56c03ab /home/acme/bin/perf
  d3ca765a8ecf257d263801d7ad8c49c189082317 /usr/lib64/libdwarf.so.0.0
  acme@parisc:~/git/linux-2.6-tip$

  acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm
  The file [kernel.kallsyms] cannot be used, trying to use /proc/kallsyms...

  ^^^^ The problem related to vmlinux handling, it shouldn't be trying this
  ^^^^ rather alien /proc/kallsyms at all...

  /lib64/libpthread-2.10.2.so with build id 5c68f7afeb33309c78037e374b0deee84dd441f6 not found, continuing without symbols
  /lib64/libc-2.10.2.so with build id eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 not found, continuing without symbols
  /home/acme/bin/perf with build id a83ecfb519a788774a84d5ddde633c9ba56c03ab not found, continuing without symbols
  /usr/sbin/openvpn with build id f2037a091ef36b591187a858d75e203690ea9409 not found, continuing without symbols
  Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/e1000e/e1000e.ko, continuing without symbols
  Failed to open /lib/modules/2.6.33-rc4-tip+/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko, continuing without symbols

  <SNIP more complaints about not finding the right build-ids,
        those will have to wait for 'perf archive' or plain
        copying what was collected by 'perf record' on the x86_64,
        source machine, see further below for an example of this >

  # Samples: 293085637
  #
  # Overhead          Command
  # ........  ...............
  #
      61.70%             find
      23.50%             perf
       5.86%          swapper
       3.12%             sshd
       2.39%             init
       0.87%             bash
       0.86%            sleep
       0.59%      dbus-daemon
       0.25%             hald
       0.24%   NetworkManager
       0.19%  hald-addon-rfki
       0.15%          openvpn
       0.07%             phy0
       0.07%         events/0
       0.05%          iwl3945
       0.05%         events/1
       0.03%      kondemand/0
  acme@parisc:~/git/linux-2.6-tip$

Which matches what we get when running the same command for the
same perf.data file on the F12, x86_64, source machine:

  [root@doppio linux-2.6-tip]# perf report --sort comm
  # Samples: 293085637
  #
  # Overhead          Command
  # ........  ...............
  #
      61.70%             find
      23.50%             perf
       5.86%          swapper
       3.12%             sshd
       2.39%             init
       0.87%             bash
       0.86%            sleep
       0.59%      dbus-daemon
       0.25%             hald
       0.24%   NetworkManager
       0.19%  hald-addon-rfki
       0.15%          openvpn
       0.07%             phy0
       0.07%         events/0
       0.05%          iwl3945
       0.05%         events/1
       0.03%      kondemand/0
  [root@doppio linux-2.6-tip]#

The other modes work as well, modulo the problem with vmlinux:

  acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso 2> /dev/null | head -15
  # Samples: 293085637
  #
  # Overhead          Command                      Shared Object
  # ........  ...............  .................................
  #
      35.11%             find                   ffffffff81002b5a
      18.25%             perf                   ffffffff8102235f
      16.17%             find  libc-2.10.2.so
       9.07%             find  find
       5.80%          swapper                   ffffffff8102235f
       3.95%             perf  libc-2.10.2.so
       2.33%             init                   ffffffff810091b9
       1.65%             sshd  libcrypto.so.0.9.8k
       1.35%             find  [e1000e]
       0.68%            sleep  libc-2.10.2.so
  acme@parisc:~/git/linux-2.6-tip$

And the lack of the right buildids:

  acme@parisc:~/git/linux-2.6-tip$ perf report --sort comm,dso,symbol 2> /dev/null | head -15
  # Samples: 293085637
  #
  # Overhead          Command                      Shared Object  Symbol
  # ........  ...............  .................................  ......
  #
      35.11%             find                   ffffffff81002b5a  [k] 0xffffffff81002b5a
      18.25%             perf                   ffffffff8102235f  [k] 0xffffffff8102235f
      16.17%             find  libc-2.10.2.so                     [.] 0x00000000045782
       9.07%             find  find                               [.] 0x0000000000fb0e
       5.80%          swapper                   ffffffff8102235f  [k] 0xffffffff8102235f
       3.95%             perf  libc-2.10.2.so                     [.] 0x0000000007f398
       2.33%             init                   ffffffff810091b9  [k] 0xffffffff810091b9
       1.65%             sshd  libcrypto.so.0.9.8k                [.] 0x00000000105440
       1.35%             find  [e1000e]                           [k] 0x00000000010948
       0.68%            sleep  libc-2.10.2.so                     [.] 0x0000000011ad5b
  acme@parisc:~/git/linux-2.6-tip$

But if we:

  acme@parisc:~/git/linux-2.6-tip$ ls ~/.debug
  ls: cannot access /home/acme/.debug: No such file or directory
  acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/lib64/libc-2.10.2.so/
  acme@parisc:~/git/linux-2.6-tip$ scp doppio:.debug/lib64/libc-2.10.2.so/* ~/.debug/lib64/libc-2.10.2.so/
  acme@doppio's password:
  eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1	             100% 1783KB 714.7KB/s   00:02
  acme@parisc:~/git/linux-2.6-tip$ mkdir -p ~/.debug/.build-id/eb
  acme@parisc:~/git/linux-2.6-tip$ ln -s ../../lib64/libc-2.10.2.so/eb4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1 ~/.debug/.build-id/eb/4ec8fa8b2a5eb18cad173c92f27ed8887ed1c1
  acme@parisc:~/git/linux-2.6-tip$ perf report --dsos libc-2.10.2.so 2> /dev/null
  # dso: libc-2.10.2.so
  # Samples: 64281170
  #
  # Overhead          Command  Symbol
  # ........  ...............  ......
  #
      14.98%             perf  [.] __GI_strcmp
      12.30%             find  [.] __GI_memmove
       9.25%             find  [.] _int_malloc
       7.60%             find  [.] _IO_vfprintf_internal
       6.10%             find  [.] _IO_new_file_xsputn
       6.02%             find  [.] __GI_close
       3.08%             find  [.] _IO_file_overflow_internal
       3.08%             find  [.] malloc_consolidate
       3.08%             find  [.] _int_free
       3.08%             find  [.] __strchrnul
       3.08%             find  [.] __getdents64
       3.08%             find  [.] __write_nocancel
       3.08%            sleep  [.] __GI__dl_addr
       3.08%             sshd  [.] __libc_select
       3.08%             find  [.] _IO_new_file_write
       3.07%             find  [.] _IO_new_do_write
       3.06%             find  [.] __GI___errno_location
       3.05%             find  [.] __GI___libc_malloc
       3.04%             perf  [.] __GI_memcpy
       1.71%             find  [.] __fprintf_chk
       1.29%             bash  [.] __gconv_transform_utf8_internal
       0.79%      dbus-daemon  [.] __GI_strlen
  #
  # (For a higher level overview, try: perf report --sort comm,dso)
  #
  acme@parisc:~/git/linux-2.6-tip$

Which matches what we get on the source, F12, x86_64 machine:

  [root@doppio linux-2.6-tip]# perf report --dsos libc-2.10.2.so
  # dso: libc-2.10.2.so
  # Samples: 64281170
  #
  # Overhead          Command  Symbol
  # ........  ...............  ......
  #
      14.98%             perf  [.] __GI_strcmp
      12.30%             find  [.] __GI_memmove
       9.25%             find  [.] _int_malloc
       7.60%             find  [.] _IO_vfprintf_internal
       6.10%             find  [.] _IO_new_file_xsputn
       6.02%             find  [.] __GI_close
       3.08%             find  [.] _IO_file_overflow_internal
       3.08%             find  [.] malloc_consolidate
       3.08%             find  [.] _int_free
       3.08%             find  [.] __strchrnul
       3.08%             find  [.] __getdents64
       3.08%             find  [.] __write_nocancel
       3.08%            sleep  [.] __GI__dl_addr
       3.08%             sshd  [.] __libc_select
       3.08%             find  [.] _IO_new_file_write
       3.07%             find  [.] _IO_new_do_write
       3.06%             find  [.] __GI___errno_location
       3.05%             find  [.] __GI___libc_malloc
       3.04%             perf  [.] __GI_memcpy
       1.71%             find  [.] __fprintf_chk
       1.29%             bash  [.] __gconv_transform_utf8_internal
       0.79%      dbus-daemon  [.] __GI_strlen
  #
  # (For a higher level overview, try: perf report --sort comm,dso)
  #
  [root@doppio linux-2.6-tip]#

So I think this is really, really nice in that it demonstrates
the portability of perf.data files and the use of build-ids
accross such aliens worlds :-)

There are some things to fix tho, like the bitmap on the header,
but things are looking good.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-01-16 10:58:45 +01:00
Arnaldo Carvalho de Melo ae99fb2c33 perf header: perf_header__push_event() shouldn't die
Just propagate eventual errors.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1262047716-23171-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-30 11:59:57 +01:00
Arnaldo Carvalho de Melo 94c744b6c0 perf tools: Introduce perf_session class
That does all the initialization boilerplate, opening the file,
reading the header, checking if it is valid, etc.

And that will as well have the threads list, kmap (now) global
variable, etc, so that we can handle two (or more) perf.data files
describing sessions to compare.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1260573842-19720-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-12 07:42:12 +01:00
Arnaldo Carvalho de Melo d5eed904bb perf tools: Eliminate some more die() uses in library functions
This time in perf_header__adds_write, propagating the do_write
error returns.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1258649757-17554-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-19 18:47:17 +01:00
Arnaldo Carvalho de Melo 4dc0a04bb1 perf tools: perf_header__read() shouldn't die()
And also don't call the constructor in it, this way it adheres
to the model the other methods follow.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1258649757-17554-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-19 18:47:17 +01:00
Arnaldo Carvalho de Melo 5875412152 perf tools: Don't die() in perf_header_attr__add_id()
Propagate the errors instead, the users are the ones to decide
what to do if a library call fails.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <1258427892-16312-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-17 07:19:55 +01:00
Arnaldo Carvalho de Melo 11deb1f9f6 perf tools: Don't die() in perf_header__add_attr()
Propagate the errors instead, the users are the ones to decide
what to do if a library call fails.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <1258427892-16312-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-17 07:19:54 +01:00
Arnaldo Carvalho de Melo dc79c0fc08 perf tools: Don't die in perf_header_attr__new()
We really should propagate such kinds of errors so that users of
these library functions decide what to do in such cases instead
of exiting in random places like now.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <1258407027-384-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-17 07:19:52 +01:00
Arnaldo Carvalho de Melo 37562eac37 perf tools: Generalize perf_header__adds_read()
Renaming it to perf_header__process_sections() and passing a
callback to handle each feature.

The next changesets will introduce 'perf buildid-list' that will
handle just the HEADER_BUILD_ID table, ignoring all the other
features.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <1258396365-29217-3-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-16 22:05:50 +01:00
Frederic Weisbecker 3e13ab2d83 perf tools: Use perf_header__set/has_feat whenever possible
And drop the alternate checks/sets using set_bit or other kind
of helpers.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
LKML-Reference: <1257911467-28276-5-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-11 07:30:19 +01:00
Frederic Weisbecker 8671dab9d5 perf tools: Move the build-id storage operations to headers
So that it makes easier to control it. Especially because we
plan to give it a feature section.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
LKML-Reference: <1257911467-28276-2-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-11 07:30:17 +01:00
Arnaldo Carvalho de Melo 8d06367fa7 perf symbols: Use the buildids if present
With this change 'perf record' will intercept PERF_RECORD_MMAP
calls, creating a linked list of DSOs, then when the session
finishes, it will traverse this list and read the buildids,
stashing them at the end of the file and will set up a new
feature bit in the header bitmask.

'perf report' will then notice this feature and populate the
'dsos' list and set the build ids.

When reading the symtabs it will refuse to load from a file that
doesn't have the same build id. This improves the
reliability of the profiler output, as symbols and profiling
data is more guaranteed to match.

Example:

 [root@doppio ~]# perf report | head
 /home/acme/bin/perf with build id b1ea544ac3746e7538972548a09aadecc5753868 not found, continuing without symbols
  # Samples: 2621434559
  #
  # Overhead          Command                  Shared Object  Symbol
  # ........  ...............  .............................  ......
  #
       7.91%             init  [kernel]        [k] read_hpet
       7.64%             init  [kernel]        [k] mwait_idle_with_hints
       7.60%          swapper  [kernel]        [k] read_hpet
       7.60%          swapper  [kernel]        [k] mwait_idle_with_hints
       3.65%             init  [kernel]        [k] 0xffffffffa02339d9
[root@doppio ~]#

In this case the 'perf' binary was an older one, vanished,
so its symbols probably wouldn't match or would cause subtly
different (and misleading) output.

Next patches will support the kernel as well, reading the build
id notes for it and the modules from /sys.

Another patch should also introduce a new plumbing command:

'perf list-buildids'

that will then be used in porcelain that is distro specific to
fetch -debuginfo packages where such buildids are present. This
will in turn allow for one to run 'perf record' in one machine
and 'perf report' in another.

Future work on having the buildid sent directly from the kernel
in the PERF_RECORD_MMAP event is needed to close races, as the
DSO can be changed during a 'perf record' session, but this
patch at least helps with non-corner cases and current/older
kernels.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Frank Ch. Eigler <fche@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Jim Keniston <jkenisto@us.ibm.com>
Cc: K. Prasad <prasad@linux.vnet.ibm.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roland McGrath <roland@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <1257367843-26224-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-08 10:44:36 +01:00
Frederic Weisbecker db9f11e36d perf tools: Use DECLARE_BITMAP instead of an open-coded array
Use DECLARE_BITMAP instead of an open coded array for our bitmap
of featured sections.

This makes the array an unsigned long instead of a u64 but since
we use a 256 bits bitmap, the array size shouldn't vary between
different boxes.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <1255795038-13751-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-19 09:26:35 +02:00
Frederic Weisbecker 2ba0825075 perf tools: Introduce bitmask'ed additional headers
This provides a new set of bitmasked headers. A new field is
added in the perf headers that implements a bitmap storing
optional features present in the perf.data file.

The layout can be pictured like this:

(Usual perf headers)(Features bitmap)[Feature 0][Feature
n][Feature 255]

If the bit n is set, then the feature n is used in this file.
They are all set in order. This brings a backward and forward
compatibility.

The trace_info section has moved into such optional features,
this is the first and only one for now.

This is backward compatible with the .32 file version although
it doesn't support the previous separate trace.info file.

And finally it doesn't support the current interim development
version.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <1255792354-11304-2-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-19 09:26:35 +02:00
Frederic Weisbecker 03456a158d perf tools: Merge trace.info content into perf.data
This drops the trace.info file and move its contents into the
common perf.data file.

This is done by creating a new trace_info section into this file. A
user of perf headers needs to call perf_header__set_trace_info() to
save the trace meta informations into the perf.data file.

A file created by perf after his patch is unsupported by previous
version because the size of the headers have increased.

That said, it's two new fields that have been added in the end of
the headers, and those could be ignored by previous versions if
they just handled the dynamic header size and then ignore the
unknow part. The offsets guarantee the compatibility. We'll do a
-stable fix for that.

But current previous versions handle the header size using its
static size, not dynamic, then it's not backward compatible with
trace records.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <20091006213643.GA5343@nowhere>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-07 08:36:10 +02:00
John Kacur 8b40f521cf perf tools: Protect header files with a consistent style
There was a colorful mix of header guards - standardize them.

Signed-off-by: John Kacur <jkacur@redhat.com>
LKML-Reference: <alpine.LFD.2.00.0909241756530.11383@localhost.localdomain>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-24 21:27:51 +02:00
Ingo Molnar cdd6c482c9 perf: Do the big rename: Performance Counters -> Performance Events
Bye-bye Performance Counters, welcome Performance Events!

In the past few months the perfcounters subsystem has grown out its
initial role of counting hardware events, and has become (and is
becoming) a much broader generic event enumeration, reporting, logging,
monitoring, analysis facility.

Naming its core object 'perf_counter' and naming the subsystem
'perfcounters' has become more and more of a misnomer. With pending
code like hw-breakpoints support the 'counter' name is less and
less appropriate.

All in one, we've decided to rename the subsystem to 'performance
events' and to propagate this rename through all fields, variables
and API names. (in an ABI compatible fashion)

The word 'event' is also a bit shorter than 'counter' - which makes
it slightly more convenient to write/handle as well.

Thanks goes to Stephane Eranian who first observed this misnomer and
suggested a rename.

User-space tooling and ABI compatibility is not affected - this patch
should be function-invariant. (Also, defconfigs were not touched to
keep the size down.)

This patch has been generated via the following script:

  FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')

  sed -i \
    -e 's/PERF_EVENT_/PERF_RECORD_/g' \
    -e 's/PERF_COUNTER/PERF_EVENT/g' \
    -e 's/perf_counter/perf_event/g' \
    -e 's/nb_counters/nb_events/g' \
    -e 's/swcounter/swevent/g' \
    -e 's/tpcounter_event/tp_event/g' \
    $FILES

  for N in $(find . -name perf_counter.[ch]); do
    M=$(echo $N | sed 's/perf_counter/perf_event/g')
    mv $N $M
  done

  FILES=$(find . -name perf_event.*)

  sed -i \
    -e 's/COUNTER_MASK/REG_MASK/g' \
    -e 's/COUNTER/EVENT/g' \
    -e 's/\<event\>/event_id/g' \
    -e 's/counter/event/g' \
    -e 's/Counter/Event/g' \
    $FILES

... to keep it as correct as possible. This script can also be
used by anyone who has pending perfcounters patches - it converts
a Linux kernel tree over to the new naming. We tried to time this
change to the point in time where the amount of pending patches
is the smallest: the end of the merge window.

Namespace clashes were fixed up in a preparatory patch - and some
stylistic fallout will be fixed up in a subsequent patch.

( NOTE: 'counters' are still the proper terminology when we deal
  with hardware registers - and these sed scripts are a bit
  over-eager in renaming them. I've undone some of that, but
  in case there's something left where 'counter' would be
  better than 'event' we can undo that on an individual basis
  instead of touching an otherwise nicely automated patch. )

Suggested-by: Stephane Eranian <eranian@google.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Paul Mackerras <paulus@samba.org>
Reviewed-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <linux-arch@vger.kernel.org>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-21 14:28:04 +02:00
Arjan van de Ven 8755a8f27a perf: Store trace event name/id pairs in perf.data
The trace event name<->id mapping is dynamic for each kernel
compile. In order for perf.data to be useable outside the actual
system, we thus need to store a table of this mapping for later
use.

This patch adds this table to perf.data, and provides helper
functions for lookup up fields from this table.

To avoid mistakes, lookup-from-table is kept completely seprate
from lookup-from-local-debugfs.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <20090912130405.6960d099@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-19 11:42:11 +02:00
Frederic Weisbecker 0d3a5c8859 perf tools: Librarize sample type and attr finding from headers
Librarize the sample type and attr fetching from perf data file
headers so that we can also use it from perf trace.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1250448997-30715-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-16 23:06:44 +02:00
Arjan van de Ven dfe5a50461 perf: avoid structure size confusion by using a fixed size
for some reason, this structure gets compiled as 36 bytes in some files
(the ones that alloacte it) but 40 bytes in others (the ones that use it).
The cause is an off_t type that gets a different size in different
compilation units for some yet-to-be-explained reason.

But the effect is disasterous; the size/offset members of the struct
are at different offsets, and result in mostly complete garbage.
The parser in perf is so robust that this all gets hidden, and after
skipping an certain amount of samples, it recovers.... so this bug
is not normally noticed.

.... except when you want every sample to be exact.

Fix this by just using an explicitly sized type.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <4A655917.9080504@linux.intel.com>
2009-07-22 18:05:57 +02:00
Peter Zijlstra 7c6a1c65bb perf_counter tools: Rework the file format
Create a structured file format that includes the full
perf_counter_attr and all its relevant counter IDs so that
the reporting program has full information.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-06-25 21:39:04 +02:00