1. 25 7月, 2012 1 次提交
  2. 28 6月, 2012 1 次提交
    • A
      perf tools: Stop using a global trace events description list · da378962
      Arnaldo Carvalho de Melo 提交于
      The pevent thing is per perf.data file, so I made it stop being static
      and become a perf_session member, so tools processing perf.data files
      use perf_session and _there_ we read the trace events description into
      session->pevent and then change everywhere to stop using that single
      global pevent variable and use the per session one.
      
      Note that it _doesn't_ fall backs to trace__event_id, as we're not
      interested at all in what is present in the
      /sys/kernel/debug/tracing/events in the workstation doing the analysis,
      just in what is in the perf.data file.
      
      This patch also introduces perf_session__set_tracepoints_handlers that
      is the perf perf.data/session way to associate handlers to tracepoint
      events by resolving their IDs using the events descriptions stored in a
      perf.data file. Make 'perf sched' use it.
      Reported-by: NDmitry Antipov <dmitry.antipov@linaro.org>
      Tested-by: NDmitry Antipov <dmitry.antipov@linaro.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linaro-dev@lists.linaro.org
      Cc: patches@linaro.org
      Link: http://lkml.kernel.org/r/20120625232016.GA28525@infradead.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      da378962
  3. 20 6月, 2012 1 次提交
  4. 12 6月, 2012 1 次提交
    • A
      perf tools: Fix synthesizing tracepoint names from the perf.data headers · cb9dd49e
      Arnaldo Carvalho de Melo 提交于
      We need to use the per event info snapshoted at record time to
      synthesize the events name, so do it just after reading the perf.data
      headers, when we already processed the /sys events data, otherwise we'll
      end up using the local /sys that only by sheer luck will have the same
      tracepoint ID -> real event association.
      
      Example:
      
        # uname -a
        Linux felicio.ghostprotocols.net 3.4.0-rc5+ #1 SMP Sat May 19 15:27:11 BRT 2012 x86_64 x86_64 x86_64 GNU/Linux
        # perf record -e sched:sched_switch usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.015 MB perf.data (~648 samples) ]
        # cat /t/events/sched/sched_switch/id
        279
        # perf evlist -v
        sched:sched_switch: sample_freq=1, type: 2, config: 279, size: 80, sample_type: 1159, read_format: 7, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1
        #
      
      So on the above machine the sched:sched_switch has tracepoint id 279, but on
      the machine were we'll analyse it it has a different id:
      
        $ cat /t/events/sched/sched_switch/id
        56
        $ perf evlist -i /tmp/perf.data
        kmem:mm_balancedirty_writeout
        $ cat /t/events/kmem/mm_balancedirty_writeout/id
        279
      
      With this fix:
      
        $ perf evlist -i /tmp/perf.data
        sched:sched_switch
      Reported-by: NDmitry Antipov <dmitry.antipov@linaro.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-auwks8fpuhmrdpiefs55o5oz@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cb9dd49e
  5. 11 6月, 2012 1 次提交
  6. 22 5月, 2012 1 次提交
  7. 02 5月, 2012 1 次提交
  8. 24 4月, 2012 1 次提交
  9. 23 3月, 2012 1 次提交
  10. 14 3月, 2012 1 次提交
  11. 09 3月, 2012 4 次提交
  12. 14 2月, 2012 2 次提交
  13. 09 2月, 2012 1 次提交
    • S
      perf tools: fix endianness detection in perf.data · 73323f54
      Stephane Eranian 提交于
      The current version of perf detects whether or not the perf.data file is
      written in a different endianness using the attr_size field in the
      header of the file. This field represents sizeof(struct perf_event_attr)
      as known to perf record. If the sizes do not match, then perf tries the
      byte-swapped version. If they match, then the tool assumes a different
      endianness.
      
      The issue with the approach is that it assumes the size of
      perf_event_attr always has to match between perf record and perf report.
      However, the kernel perf_event ABI is extensible.  New fields can be
      added to struct perf_event_attr. Consequently, it is not possible to use
      attr_size to detect endianness.
      
      This patch takes another approach by using the magic number written at
      the beginning of the perf.data file to detect endianness. The magic
      number is an eight-byte signature.  It's primary purpose is to identify
      (signature) a perf.data file. But it could also be used to encode the
      endianness.
      
      The patch introduces a new value for this signature. The key difference
      is that the signature is written differently in the file depending on
      the endianness. Thus, by comparing the signature from the file with the
      tool's own signature it is possible to detect endianness. The new
      signature is "PERFILE2".
      
      Backward compatiblity with existing perf.data file is ensured.
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Cc: Arun Sharma <asharma@fb.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roberto Agostino Vitillo <ravitillo@lbl.gov>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Vince Weaver <vweaver1@eecs.utk.edu>
      Link: http://lkml.kernel.org/r/1328187288-24395-15-git-send-email-eranian@google.comSigned-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      73323f54
  14. 31 1月, 2012 1 次提交
  15. 25 1月, 2012 1 次提交
  16. 30 12月, 2011 1 次提交
  17. 24 12月, 2011 5 次提交
  18. 06 12月, 2011 1 次提交
  19. 28 11月, 2011 5 次提交
  20. 26 10月, 2011 1 次提交
    • A
      perf header: Fix build on old systems · a9072bc0
      Arnaldo Carvalho de Melo 提交于
      For instance, on Fedora 8:
      
      CC /home/acme/git/build/perf/util/header.o
      cc1: warnings being treated as errors
      util/header.c: In function ‘write_cpudesc’:
      util/header.c:281: warning: implicit declaration of function ‘getline’
      util/header.c:281: warning: nested extern declaration of ‘getline’
      make: *** [/home/acme/git/build/perf/util/header.o] Error 1
      make: Leaving directory `/home/acme/git/linux/tools/perf'
      [acme@localhost linux]$
      
      This happens due to header ordering, in perf util.h sets _GNU_SOURCE, so
      it must come first.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-alfra9wao63euguj7gr8jw7e@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a9072bc0
  21. 20 10月, 2011 1 次提交
    • J
      perf tools: Fix tracing info recording · 29208e57
      Jiri Olsa 提交于
      Fixing the way the tracing information is stored within record command.
      The current implementation is causing issues for pipe output.
      
      Following commands fail currently:
      	perf script syscall-counts ls
      	perf record -e syscalls:sys_exit_read ls | ./perf report -i -
      
      The tracing information is part of the perf data file. It contains
      several files from within the tracing debugfs and procs directories.
      
      Beside some static header files, for each tracing event the format
      file is added. The /proc/kallsyms file is also added.
      
      The tracing data are stored with preceeding size. This is causing some
      dificulties for pipe output, since there's no way to tell debugfs/proc
      file size before reading it. So, for pipe output, all the debugfs files
      were read twice. Once to get the overall size and once to store the
      content itself. This can cause problem in case any of these file
      changed, within the storage time.
      
      To fix this behaviour and ensure the integrity of the tracing data, we:
          - read debugfs/proc file into the temp file
          - get temp file size and dump it to the pipe
          - dump the temp file contents to the pipe
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/20111020135943.GD2092@jolsa.brq.redhat.comSigned-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      29208e57
  22. 19 10月, 2011 2 次提交
    • D
      perf tools: handle endianness of feature bitmap · d327fa43
      David Ahern 提交于
      Feature bitmap is declared as an array of unsigned longs -- not good
      since its size can differ between the host that generated the data file
      and the host analyzing the file.
      
      We need to handle endianness, but we don't know the size of the unsigned
      long where the file was generated. Take a best guess at determining it:
      try 64-bit swap first (ie., file created on a 64-bit host), and check if
      the hostname feature bit is set (this feature bit is forced on as of
      fbe96f29).  If the bit is not, undo the 64-bit swap and try a 32-bit
      swap. If the hostname bit is still not set (e.g., older data file), punt
      and fallback to the original behavior -- clearing all feature bits and
      setting buildid.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1318980841-12616-1-git-send-email-dsahern@gmail.comSigned-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d327fa43
    • D
      perf script: Fix unknown feature comment · 51192de3
      David Ahern 提交于
      "perf script -v" emits:
      
      unknown feature 3, continuing...
      unknown feature 4, continuing...
      unknown feature 5, continuing...
      unknown feature 6, continuing...
      unknown feature 7, continuing...
      unknown feature 8, continuing...
      unknown feature 9, continuing...
      unknown feature 10, continuing...
      unknown feature 11, continuing...
      unknown feature 12, continuing...
      unknown feature 13, continuing...
      unknown feature 14, continuing...
      
      These are all new features added by fbe96f29. Update
      perf_file_section__process to know they are valid feature ids.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1318984464-20650-1-git-send-email-dsahern@gmail.comSigned-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      51192de3
  23. 14 10月, 2011 1 次提交
  24. 08 10月, 2011 1 次提交
    • S
      perf tools: Make perf.data more self-descriptive (v8) · fbe96f29
      Stephane Eranian 提交于
      The goal of this patch is to include more information about the host
      environment into the perf.data so it is more self-descriptive. Overtime,
      profiles are captured on various machines and it becomes hard to track
      what was recorded, on what machine and when.
      
      This patch provides a way to solve this by extending the perf.data file
      with basic information about the host machine. To add those extensions,
      we leverage the feature bits capabilities of the perf.data format.  The
      change is backward compatible with existing perf.data files.
      
      We define the following useful new extensions:
       - HEADER_HOSTNAME: the hostname
       - HEADER_OSRELEASE: the kernel release number
       - HEADER_ARCH: the hw architecture
       - HEADER_CPUDESC: generic CPU description
       - HEADER_NRCPUS: number of online/avail cpus
       - HEADER_CMDLINE: perf command line
       - HEADER_VERSION: perf version
       - HEADER_TOPOLOGY: cpu topology
       - HEADER_EVENT_DESC: full event description (attrs)
       - HEADER_CPUID: easy-to-parse low level CPU identication
      
      The small granularity for the entries is to make it easier to extend
      without breaking backward compatiblity. Many entries are provided as
      ASCII strings.
      
      Perf report/script have been modified to print the basic information as
      easy-to-parse ASCII strings. Extended information about CPU and NUMA
      topology may be requested with the -I option.
      
      Thanks to David Ahern for reviewing and testing the many versions of
      this patch.
      
       $ perf report --stdio
       # ========
       # captured on : Mon Sep 26 15:22:14 2011
       # hostname : quad
       # os release : 3.1.0-rc4-tip
       # perf version : 3.1.0-rc4
       # arch : x86_64
       # nrcpus online : 4
       # nrcpus avail : 4
       # cpudesc : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
       # cpuid : GenuineIntel,6,15,11
       # total memory : 8105360 kB
       # cmdline : /home/eranian/perfmon/official/tip/build/tools/perf/perf record date
       # event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, id = { 29, 30, 31,
       # HEADER_CPU_TOPOLOGY info available, use -I to display
       # HEADER_NUMA_TOPOLOGY info available, use -I to display
       # ========
       #
       ...
      
       $ perf report --stdio -I
       # ========
       # captured on : Mon Sep 26 15:22:14 2011
       # hostname : quad
       # os release : 3.1.0-rc4-tip
       # perf version : 3.1.0-rc4
       # arch : x86_64
       # nrcpus online : 4
       # nrcpus avail : 4
       # cpudesc : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
       # cpuid : GenuineIntel,6,15,11
       # total memory : 8105360 kB
       # cmdline : /home/eranian/perfmon/official/tip/build/tools/perf/perf record date
       # event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, id = { 29, 30, 31,
       # sibling cores   : 0-3
       # sibling threads : 0
       # sibling threads : 1
       # sibling threads : 2
       # sibling threads : 3
       # node0 meminfo  : total = 8320608 kB, free = 7571024 kB
       # node0 cpu list : 0-3
       # ========
       #
       ...
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Link: http://lkml.kernel.org/r/20110930134040.GA5575@quadSigned-off-by: NStephane Eranian <eranian@google.com>
      [ committer notes: Use --show-info in the tools as was in the docs, rename
        perf_header_fprintf_info to perf_file_section__fprintf_info, fixup
        conflict with f69b64f7 "perf: Support setting the disassembler style" ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fbe96f29
  25. 11 8月, 2011 1 次提交
    • J
      perf report: Use properly build_id kernel binaries · f57b05ed
      Jiri Olsa 提交于
      If we bring the recorded perf data together with kernel binary from another
      machine using:
      
      	on server A:
      	perf archive
      
      	on server B:
      	tar xjvf perf.data.tar.bz2 -C ~/.debug
      
      the build_id kernel dso is not properly recognized during the "perf report"
      command on server B.
      
      The reason is, that build_id dsos are added during the session initialization,
      while the kernel maps are created during the sample event processing.
      
      The machine__create_kernel_maps functions ends up creating new dso object for
      kernel, but it does not check if we already have one added by build_id
      processing.
      
      Also the build_id reading ABI quirk added in commit:
      
       - commit b2511481
         perf build-id: Add quirk to deal with perf.data file format breakage
      
      populates the "struct build_id_event::pid" with 0, which
      is later interpreted as DEFAULT_GUEST_KERNEL_ID.
      
      This is not always correct, so it's better to guess the pid
      value based on the "struct build_id_event::header::misc" value.
      
      - Tested with data generated on x86 kernel version v2.6.34
        and reported back on x86_64 current kernel.
      - Not tested for guest kernel case.
      
      Note the problem stays for PERF_RECORD_MMAP events recorded by perf that
      does not use proper pid (HOST_KERNEL_ID/DEFAULT_GUEST_KERNEL_ID). They are
      misinterpreted within the current perf code. Probably there's not much we
      can do about that.
      
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20110601194346.GB1934@jolsa.brq.redhat.comSigned-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f57b05ed
  26. 22 7月, 2011 1 次提交
  27. 21 7月, 2011 1 次提交