linux-toradex.git/tools/perf/util/session.c, branch v2.6.34

perf session: Add storage for seperating event types in report

2010-03-10T12:53:48+00:00

This patch adds the structures necessary to count each event
type independently in perf report.

Signed-off-by: Eric B Munson 
Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <1267804269-22660-4-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

perf tools: Clean up O_LARGEFILE et al usage

2010-02-04T09:03:03+00:00

Setting _FILE_OFFSET_BITS and using O_LARGEFILE, lseek64, etc,
is redundant. Thanks H. Peter Anvin for pointing it out.

So, this patch removes O_LARGEFILE, lseek64, etc.

Suggested-by: "H. Peter Anvin" 
Signed-off-by: Xiao Guangrong 
Cc: Frederic Weisbecker 
Cc: Steven Rostedt 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
LKML-Reference: <4B6A8972.3070605@cn.fujitsu.com>
Signed-off-by: Ingo Molnar

perf record: Stop intercepting events, use postprocessing to get build-ids

2010-02-04T08:33:27+00:00

We want to stream events as fast as possible to perf.data, and
also in the future we want to have splice working, when no
interception will be possible.

Using build_id__mark_dso_hit_ops to create the list of DSOs that
back MMAPs we also optimize disk usage in the build-id cache by
only caching DSOs that had hits.

Suggested-by: Peter Zijlstra 
Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Xiao Guangrong 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Paul Mackerras 
LKML-Reference: <1265223128-11786-6-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

perf symbols: Remove perf_session usage in symbols layer

2010-02-04T08:33:24+00:00

I noticed while writing the first test in 'perf regtest' that to
just test the symbol handling routines one needs to create a
perf session, that is a layer centered on a perf.data file,
events, etc, so I untied these layers.

This reduces the complexity for the users as the number of
parameters to most of the symbols and session APIs now was
reduced while not adding more state to all the map instances by
only having data that is needed to split the kernel (kallsyms
and ELF symtab sections) maps and do vmlinux relocation on the
main kernel map.

Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <1265223128-11786-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

perf tools: Use O_LARGEFILE to open perf data file

2010-02-03T08:03:59+00:00

Open perf data file with O_LARGEFILE flag since its size is
easily larger that 2G.

For example:

 # rm -rf perf.data
 # ./perf kmem record sleep 300

 [ perf record: Woken up 0 times to write data ]
 [ perf record: Captured and wrote 3142.147 MB perf.data
 (~137282513 samples) ]

 # ll -h perf.data
 -rw------- 1 root root 3.1G .....

Signed-off-by: Xiao Guangrong 
Cc: Frederic Weisbecker 
Cc: Steven Rostedt 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
LKML-Reference: <4B68F32A.9040203@cn.fujitsu.com>
Signed-off-by: Ingo Molnar

perf session: Create kernel maps in the constructor

2010-01-29T08:20:58+00:00

Removing one extra step needed in the tools that need this,
fixing a bug in 'perf probe' where this was not being done.

Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Masami Hiramatsu 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <1264633557-17597-4-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

perf tools: Convert getpagesize() uses to sysconf(_SC_GETPAGESIZE)

2010-01-16T09:58:46+00:00

Using the more portable and equivalent sysconf call.

Reported-by: Aristeu Rozanski 
Reported-by: Ulrich Drepper 
Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Aristeu Rozanski 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Ulrich Drepper 
LKML-Reference: <1263501006-14185-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

perf tools: Cross platform perf.data analysis support

2010-01-16T09:58:45+00:00

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

  

  # 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 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <1263478990-8200-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

perf tools: Don't cast RIP to pointers

2010-01-16T09:58:45+00:00

Since they can come from another architecture with bigger
pointers, i.e. processing a 64-bit perf.data on a 32-bit arch.

Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <1263478990-8200-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

perf tools: Encode kernel module mappings in perf.data

2010-01-13T16:39:43+00:00

We were always looking at the running machine /proc/modules,
even when processing a perf.data file, which only makes sense
when we're doing 'perf record' and 'perf report' on the same
machine, and in close sucession, or if we don't use modules at
all, right Peter? ;-)

Now, at 'perf record' time we read /proc/modules, find the long
path for modules, and put them as PERF_MMAP events, just like we
did to encode the reloc reference symbol for vmlinux. Talking
about that now it is encoded in .pgoff, so that we can use
.{start,len} to store the address boundaries for the kernel so
that when we reconstruct the kmaps tree we can do lookups right
away, without having to fixup the end of the kernel maps like we
did in the past (and now only in perf record).

One more step in the 'perf archive' direction when we'll finally
be able to collect data in one machine and analyse in another.

Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar