1. 02 5月, 2010 1 次提交
  2. 28 4月, 2010 1 次提交
    • A
      perf tools: Rename "kernel_info" to "machine" · 23346f21
      Arnaldo Carvalho de Melo 提交于
      struct kernel_info and kerninfo__ are too vague, what they really
      describe are machines, virtual ones or hosts.
      
      There are more changes to introduce helpers to shorten function calls
      and to make more clear what is really being done, but I left that for
      subsequent patches.
      
      Cc: Avi Kivity <avi@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>
      Cc: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      23346f21
  3. 19 4月, 2010 1 次提交
  4. 14 4月, 2010 5 次提交
    • T
      perf: Convert perf header build_ids into build_id events · c7929e47
      Tom Zanussi 提交于
      Bypasses the build_id perf header code and replaces it with a
      synthesized event and processing function that accomplishes the
      same thing, used when reading/writing perf data to/from a pipe.
      Signed-off-by: NTom Zanussi <tzanussi@gmail.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: fweisbec@gmail.com
      Cc: rostedt@goodmis.org
      Cc: k-keiichi@bx.jp.nec.com
      Cc: acme@ghostprotocols.net
      LKML-Reference: <1270184365-8281-9-git-send-email-tzanussi@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7929e47
    • T
      perf: Convert perf tracing data into a tracing_data event · 9215545e
      Tom Zanussi 提交于
      Bypasses the tracing_data perf header code and replaces it with
      a synthesized event and processing function that accomplishes
      the same thing, used when reading/writing perf data to/from a
      pipe.
      
      The tracing data is pretty large, and this patch doesn't attempt
      to break it down into component events.  The tracing_data event
      itself doesn't actually contain the tracing data, rather it
      arranges for the event processing code to skip over it after
      it's read, using the skip return value added to the event
      processing loop in a previous patch.
      Signed-off-by: NTom Zanussi <tzanussi@gmail.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: fweisbec@gmail.com
      Cc: rostedt@goodmis.org
      Cc: k-keiichi@bx.jp.nec.com
      Cc: acme@ghostprotocols.net
      LKML-Reference: <1270184365-8281-8-git-send-email-tzanussi@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9215545e
    • T
      perf: Convert perf event types into event type events · cd19a035
      Tom Zanussi 提交于
      Bypasses the event type perf header code and replaces it with a
      synthesized event and processing function that accomplishes the
      same thing, used when reading/writing perf data to/from a pipe.
      Signed-off-by: NTom Zanussi <tzanussi@gmail.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: fweisbec@gmail.com
      Cc: rostedt@goodmis.org
      Cc: k-keiichi@bx.jp.nec.com
      Cc: acme@ghostprotocols.net
      LKML-Reference: <1270184365-8281-7-git-send-email-tzanussi@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cd19a035
    • T
      perf: Convert perf header attrs into attr events · 2c46dbb5
      Tom Zanussi 提交于
      Bypasses the attr perf header code and replaces it with a
      synthesized event and processing function that accomplishes the
      same thing, used when reading/writing perf data to/from a pipe.
      
      Making the attrs into events allows them to be streamed over a
      pipe along with the rest of the header data (in later patches).
      It also paves the way to allowing events to be added and removed
      from perf sessions dynamically.
      Signed-off-by: NTom Zanussi <tzanussi@gmail.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: fweisbec@gmail.com
      Cc: rostedt@goodmis.org
      Cc: k-keiichi@bx.jp.nec.com
      Cc: acme@ghostprotocols.net
      LKML-Reference: <1270184365-8281-6-git-send-email-tzanussi@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2c46dbb5
    • T
      perf: Add pipe-specific header read/write and event processing code · 8dc58101
      Tom Zanussi 提交于
      This patch makes several changes to allow the perf event stream
      to be sent and received over a pipe:
      
      - adds pipe-specific versions of the header read/write code
      
      - adds pipe-specific version of the event processing code
      
      - adds a range of event types to be used for header or other
        pseudo events, above the range used by the kernel
      
      - checks the return value of event handlers, which they can use
        to skip over large events during event processing rather than actually
        reading them into event objects.
      
      - unifies the multiple do_read() functions and updates its
        users.
      
      Note that none of these changes affect the existing perf data
      file format or processing - this code only comes into play if
      perf output is sent to stdout (or is read from stdin).
      Signed-off-by: NTom Zanussi <tzanussi@gmail.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: fweisbec@gmail.com
      Cc: rostedt@goodmis.org
      Cc: k-keiichi@bx.jp.nec.com
      Cc: acme@ghostprotocols.net
      LKML-Reference: <1270184365-8281-2-git-send-email-tzanussi@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8dc58101
  5. 04 2月, 2010 2 次提交
  6. 03 2月, 2010 1 次提交
    • X
      perf tools: Use O_LARGEFILE to open perf data file · b8f46c5a
      Xiao Guangrong 提交于
      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: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <4B68F32A.9040203@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b8f46c5a
  7. 21 1月, 2010 1 次提交
    • A
      perf buildid-cache: Add new command to manage build-id cache · ef12a141
      Arnaldo Carvalho de Melo 提交于
      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: 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: <1264008525-29025-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ef12a141
  8. 16 1月, 2010 2 次提交
    • A
      perf symbols: Cache /proc/kallsyms files by build-id · 9e201442
      Arnaldo Carvalho de Melo 提交于
      So that when we don't have a vmlinux handy we can store the
      kallsyms for later use by 'perf report'.
      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: <1263501006-14185-3-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9e201442
    • 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
  9. 13 1月, 2010 2 次提交
  10. 30 12月, 2009 2 次提交
  11. 28 12月, 2009 1 次提交
    • A
      perf record: Introduce a symtab cache · 4cf40131
      Arnaldo Carvalho de Melo 提交于
      Now a cache will be created in a ~/.debug debuginfo like
      hierarchy, so that at the end of a 'perf record' session all the
      binaries (with build-ids) involved get collected and indexed by
      their build-ids, so that perf report can find them.
      
      This is interesting when developing software where you want to
      do a 'perf diff' with the previous build and opens avenues for
      lots more interesting tools, like a 'perf diff --graph' that
      takes more than two binaries into account.
      
      Tunables for collecting just the symtabs can be added if one
      doesn't want to have the full binary, but having the full binary
      allows things like 'perf rerecord' or other tools that can
      re-run the tests by having access to the exact binary in some
      perf.data file, so it may well be interesting to keep the full
      binary there.
      
      Space consumption is minimised by trying to use hard links, a
      'perf cache' tool to manage the space used, a la ccache is
      required to purge older entries.
      
      With this in place it will be possible also to introduce new
      commands, 'perf archive' and 'perf restore' (or some more
      suitable and future proof names) to create a cpio/tar file with
      the perf data and the files in the cache that _had_ perf hits of
      interest.
      
      There are more aspects to polish, like finding the right vmlinux
      file to cache, etc, but this is enough for a first step.
      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: <1261957026-15580-10-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4cf40131
  12. 14 12月, 2009 1 次提交
  13. 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
  14. 07 12月, 2009 2 次提交
  15. 28 11月, 2009 1 次提交
  16. 24 11月, 2009 3 次提交
    • A
      perf tools: Introduce zalloc() for the common calloc(1, N) case · 36479484
      Arnaldo Carvalho de Melo 提交于
      This way we type less characters and it looks more like the
      kzalloc kernel counterpart.
      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: <1259071517-3242-3-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      36479484
    • A
      perf symbols: Simplify symbol machinery setup · b32d133a
      Arnaldo Carvalho de Melo 提交于
      And also express its configuration toggles via a struct.
      
      Now all one has to do is to call symbol__init(NULL) if the
      defaults are OK, or pass a struct symbol_conf pointer with the
      desired configuration.
      
      If a tool uses kernel_maps__find_symbol() to look at the kernel
      and modules mappings for a symbol but didn't call symbol__init()
      first, that will generate a one time warning too, alerting the
      subcommand developer that symbol__init() must be called.
      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: <1259071517-3242-2-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b32d133a
    • A
      perf symbols: Look for vmlinux in more places · cc612d81
      Arnaldo Carvalho de Melo 提交于
      Now that we can check the buildid to see if it really matches,
      this can be done safely:
      
        vmlinux
        /boot/vmlinux
        /boot/vmlinux-<uts.release>
        /lib/modules/<uts.release>/build/vmlinux
        /usr/lib/debug/lib/modules/%s/vmlinux
      
      More can be added - if you know about distros that put the
      vmlinux somewhere else please let us know.
      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: <1259001550-8194-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cc612d81
  17. 21 11月, 2009 1 次提交
    • A
      perf symbols: Do lazy symtab loading for the kernel & modules too · c338aee8
      Arnaldo Carvalho de Melo 提交于
      Just like we do with the other DSOs. This also simplifies the
      kernel_maps setup process, now all that the tools need to do is
      to call kernel_maps__init and the maps for the modules and
      kernel will be created, then, later, when
      kernel_maps__find_symbol() is used, it will also call
      maps__find_symbol that already checks if the symtab was loaded,
      loading it if needed.
      
      Now if one does 'perf top --hide_kernel_symbols' we won't pay
      the price of loading the (many) symbols in /proc/kallsyms or
      vmlinux.
      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: <1258757489-5978-4-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c338aee8
  18. 20 11月, 2009 2 次提交
  19. 19 11月, 2009 3 次提交
    • A
      perf symbols: Capture the running kernel buildid too · 2446042c
      Arnaldo Carvalho de Melo 提交于
      [root@doppio linux-2.6-tip]# perf record -a -f sleep 3s ; perf
      buildid-list | grep vmlinux
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.171 MB perf.data (~7489
      samples) ] 18e7cc53db62a7d35e9d6f6c9ddc23017d38ee9a vmlinux
      [root@doppio linux-2.6-tip]#
      
      Several refactorings were needed so that we can have symmetry
      between dsos__load_modules() and dsos__load_kernel(), i.e. those
      functions will respectively create and add to the dsos list the
      loaded modules and kernel, with its buildids, but not load its
      symbols. That is something the subcomands that need will have to
      call dso__load_kernel_sym(), just like we do with modules with
      dsos__load_module_sym()/dso__load_module_sym().
      
      Next csets will actually use this info to stop producing bogus
      results using mismatched vmlinux and .ko files.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Roland McGrath <roland@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: <1258582853-8579-4-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2446042c
    • A
      perf symbols: Record the build_ids of kernel modules too · f1617b40
      Arnaldo Carvalho de Melo 提交于
      [root@doppio linux-2.6-tip]# perf record -a sleep 2s;perf
      buildid-list|tail [ perf record: Woken up 1 times to write data
      ] [ perf record: Captured and wrote 0.162 MB perf.data (~7078
      samples) ] 881588fa57b3c1696bc91e5e804a11304f093535 [cfg80211]
      4d47ce1da9d16bad00c962c072451b7c681e82df [snd_page_alloc]
      5146377e89a7caac617f9782f1a02e46263d3a31 [rfkill]
      2153b937bff0d345fea83b63a2e1d3138569f83d [i915]
      4e6fb1bb97362e3ee4d306988b9ad6912d5fb9ae [drm_kms_helper]
      f56ef2bf853e3a798f0d8d51f797622e5dc4420e [drm]
      b0d157a3b5c4e017329ffc07c64623cd6ad65e95 [i2c_algo_bit]
      8125374b905ef9fa8b65d98e166b008ad952f198 [i2c_core]
      fc875c6e5a90e7b915e9d445d0efc859e1b2678c [video]
      4b43c5006589f977e9762fdfc7ac1a92b72fca52 [output]
      [root@doppio linux-2.6-tip]#
      
      elfutils libdwfl/linux-kernel-modules.c was used as reference,
      as suggested by Roland McGrath.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Roland McGrath <roland@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: <1258582853-8579-3-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f1617b40
    • A
      perf symbols: Kill struct build_id_list and die() another day · e30a3d12
      Arnaldo Carvalho de Melo 提交于
      No need for this struct and its allocations, we can just use the
      ->build_id member we already have in struct dso, then ask for it
      to be read, and later traverse the dsos list, writing the
      buildid table to the perf.data file.
      
      As a bonus, one more die() function got killed.
      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: <1258582853-8579-2-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e30a3d12
  20. 17 11月, 2009 7 次提交