1. 16 1月, 2010 1 次提交
    • A
      perf tools: Cross platform perf.data analysis support · ba21594c
      Arnaldo Carvalho de Melo 提交于
      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: NArnaldo 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: NIngo Molnar <mingo@elte.hu>
      ba21594c
  2. 13 1月, 2010 2 次提交
    • A
      perf tools: Handle relocatable kernels · 56b03f3c
      Arnaldo Carvalho de Melo 提交于
      DSOs don't have this problem because the kernel emits a
      PERF_MMAP for each new executable mapping it performs on
      monitored threads.
      
      To fix the kernel case we simulate the same behaviour, by having
      'perf record' to synthesize a PERF_MMAP for the kernel, encoded
      like this:
      
      [root@doppio ~]# perf record -a -f sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.344 MB perf.data (~15038 samples) ]
      [root@doppio ~]# perf report -D | head -10
      
      0xd0 [0x40]: event: 1
      .
      . ... raw event: size 64 bytes
      .  0000:  01 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 ......@........
      .  0010:  00 00 00 81 ff ff ff ff 00 00 00 00 00 00 00 00 ...............
      .  0020:  00 00 00 00 00 00 00 00 5b 6b 65 72 6e 65 6c 2e ........  [kernel
      .  0030:  6b 61 6c 6c 73 79 6d 73 2e 5f 74 65 78 74 5d 00  kallsyms._text]
      .  0xd0
      [0x40]: PERF_RECORD_MMAP 0/0: [0xffffffff81000000((nil)) @ (nil)]: [kernel.kallsyms._text]
      
      I.e. we identify such event as having:
      
       .pid      = 0
       .filename = [kernel.kallsyms.REFNAME]
       .start    = REFNAME addr in /proc/kallsyms at 'perf record' time
      
      and use now a hardcoded value of '.text' for REFNAME.
      
      Then, later, in 'perf report', if there are any kernel hits and
      thus we need to resolve kernel symbols, we search for REFNAME
      and if its address changed, relocation happened and we thus must
      change the kernel mapping routines to one that uses .pgoff as
      the relocation to apply.
      
      This way we use the same mechanism used for the other DSOs and
      don't have to do a two pass in all the kernel symbols.
      Reported-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      LKML-Reference: <1262717431-1246-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      56b03f3c
    • A
      perf session: Keep pointers to the vmlinux maps · de176489
      Arnaldo Carvalho de Melo 提交于
      So that tools such as 'perf probe' don't have to lookup
      '[kernel.kallsyms]' but instead access them directly after
      perf_session__create_kernel_maps or
      map_groups__create_kernel_maps.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@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: <1262629169-22797-4-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      de176489
  3. 28 12月, 2009 5 次提交
  4. 16 12月, 2009 2 次提交
  5. 15 12月, 2009 3 次提交
  6. 14 12月, 2009 5 次提交
  7. 12 12月, 2009 1 次提交
    • A
      perf tools: Introduce perf_session class · 94c744b6
      Arnaldo Carvalho de Melo 提交于
      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: NArnaldo 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: NIngo Molnar <mingo@elte.hu>
      94c744b6