1. 14 4月, 2010 3 次提交
    • 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
  2. 08 4月, 2010 1 次提交
    • A
      perf tools: Reorganize some structs to save space · eed05fe7
      Arnaldo Carvalho de Melo 提交于
      Using 'pahole --packable' I found some structs that could be reorganized
      to eliminate alignment holes, in some cases getting them to be cacheline
      multiples.
      
      [acme@doppio linux-2.6-tip]$ codiff perf.old ~/bin/perf
      builtin-annotate.c:
        struct perf_session    |   -8
        struct perf_header     |   -8
       2 structs changed
      
      builtin-diff.c:
        struct sample_data         |   -8
       1 struct changed
        diff__process_sample_event |   -8
       1 function changed, 8 bytes removed, diff: -8
      
      builtin-sched.c:
        struct sched_atom      |   -8
       1 struct changed
      
      builtin-timechart.c:
        struct per_pid         |   -8
       1 struct changed
        cmd_timechart          |  -16
       1 function changed, 16 bytes removed, diff: -16
      
      builtin-probe.c:
        struct perf_probe_point |   -8
        struct perf_probe_event |   -8
       2 structs changed
        opt_add_probe_event     |   -3
       1 function changed, 3 bytes removed, diff: -3
      
      util/probe-finder.c:
        struct probe_finder      |   -8
       1 struct changed
        find_kprobe_trace_events |  -16
       1 function changed, 16 bytes removed, diff: -16
      
      /home/acme/bin/perf:
       4 functions changed, 43 bytes removed, diff: -43
      [acme@doppio linux-2.6-tip]$
      
      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: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      eed05fe7
  3. 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
  4. 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
  5. 30 12月, 2009 1 次提交
  6. 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
  7. 20 11月, 2009 2 次提交
  8. 17 11月, 2009 4 次提交
  9. 11 11月, 2009 2 次提交
  10. 08 11月, 2009 1 次提交
    • A
      perf symbols: Use the buildids if present · 8d06367f
      Arnaldo Carvalho de Melo 提交于
      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: NArnaldo 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: NIngo Molnar <mingo@elte.hu>
      8d06367f
  11. 19 10月, 2009 2 次提交
    • F
      perf tools: Use DECLARE_BITMAP instead of an open-coded array · db9f11e3
      Frederic Weisbecker 提交于
      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: NFrederic 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: NIngo Molnar <mingo@elte.hu>
      db9f11e3
    • F
      perf tools: Introduce bitmask'ed additional headers · 2ba08250
      Frederic Weisbecker 提交于
      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: NFrederic 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: NIngo Molnar <mingo@elte.hu>
      2ba08250
  12. 07 10月, 2009 1 次提交
    • F
      perf tools: Merge trace.info content into perf.data · 03456a15
      Frederic Weisbecker 提交于
      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: NFrederic 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: NIngo Molnar <mingo@elte.hu>
      03456a15
  13. 25 9月, 2009 1 次提交
  14. 21 9月, 2009 1 次提交
    • I
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar 提交于
      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: NStephane Eranian <eranian@google.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NArjan 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: NIngo Molnar <mingo@elte.hu>
      cdd6c482
  15. 19 9月, 2009 1 次提交
  16. 17 8月, 2009 1 次提交
  17. 23 7月, 2009 1 次提交
    • A
      perf: avoid structure size confusion by using a fixed size · dfe5a504
      Arjan van de Ven 提交于
      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: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <4A655917.9080504@linux.intel.com>
      dfe5a504
  18. 26 6月, 2009 1 次提交