1. 19 3月, 2014 2 次提交
  2. 15 3月, 2014 2 次提交
  3. 10 3月, 2014 1 次提交
  4. 18 2月, 2014 3 次提交
  5. 01 2月, 2014 2 次提交
  6. 16 1月, 2014 1 次提交
  7. 13 1月, 2014 1 次提交
  8. 28 12月, 2013 1 次提交
  9. 13 12月, 2013 1 次提交
  10. 11 12月, 2013 4 次提交
  11. 05 12月, 2013 1 次提交
  12. 15 11月, 2013 1 次提交
  13. 13 11月, 2013 1 次提交
  14. 12 11月, 2013 2 次提交
  15. 04 11月, 2013 1 次提交
  16. 22 10月, 2013 1 次提交
    • W
      perf report: Add --max-stack option to limit callchain stack scan · 91e95617
      Waiman Long 提交于
      When callgraph data was included in the perf data file, it may take a
      long time to scan all those data and merge them together especially if
      the stored callchains are long and the perf data file itself is large,
      like a Gbyte or so.
      
      The callchain stack is currently limited to PERF_MAX_STACK_DEPTH (127).
      This is a large value. Usually the callgraph data that developers are
      most interested in are the first few levels, the rests are usually not
      looked at.
      
      This patch adds a new --max-stack option to perf-report to limit the
      depth of callchain stack data to look at to reduce the time it takes for
      perf-report to finish its processing. It trades the presence of trailing
      stack information with faster speed.
      
      The following table shows the elapsed time of doing perf-report on a
      perf.data file of size 985,531,828 bytes.
      
        --max_stack   Elapsed Time    Output data size
        -----------   ------------    ----------------
        not set        88.0s          124,422,651
        64             87.5s          116,303,213
        32             87.2s          112,023,804
        16             86.6s           94,326,380
        8              59.9s           33,697,248
        4              40.7s           10,116,637
        -g none        27.1s            2,555,810
      Signed-off-by: NWaiman Long <Waiman.Long@hp.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Aswin Chandramouleeswaran <aswin@hp.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Scott J Norton <scott.norton@hp.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1382107129-2010-4-git-send-email-Waiman.Long@hp.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      91e95617
  17. 11 10月, 2013 4 次提交
  18. 25 9月, 2013 1 次提交
  19. 11 9月, 2013 1 次提交
    • S
      perf tools: Add attr->mmap2 support · 5c5e854b
      Stephane Eranian 提交于
      This patch adds support for the new PERF_RECORD_MMAP2 record type
      exposed by the kernel. This is an extended PERF_RECORD_MMAP record.
      
      It adds for each file-backed mapping the device major, minor number and
      the inode number and generation.
      
      This triplet uniquely identifies the source of a file-backed mapping. It
      can be used to detect identical virtual mappings between processes, for
      instance.
      
      The patch will prefer MMAP2 over MMAP.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1377079825-19057-3-git-send-email-eranian@google.com
      [ Cope with 314add6b "Change machine__findnew_thread() to set thread pid",
        fix 'perf test' regression test entry affected,
        use perf_missing_features.mmap2 to fallback to not using .mmap2 in older kernels,
        so that new tools can work with kernels where this feature is not present ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c5e854b
  20. 29 8月, 2013 1 次提交
  21. 27 8月, 2013 2 次提交
    • A
      perf tools: Add pid to struct thread · 99d725fc
      Adrian Hunter 提交于
      Record pid on struct thread.  The member is named 'pid_' to avoid
      confusion with the 'tid' member which was previously named 'pid'.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      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/r/1377522030-27870-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      99d725fc
    • D
      perf tools: Sample after exit loses thread correlation · 236a3bbd
      David Ahern 提交于
      Occassionally events (e.g., context-switch, sched tracepoints) are losing
      the conversion of sample data associated with a thread. For example:
      
      $ perf record -e sched:sched_switch -c 1 -a -- sleep 5
      $ perf script
      <selected events shown>
          ls 30482 [000] 1379727.583037: sched:sched_switch: prev_comm=ls prev_pid=30482 ...
          ls 30482 [000] 1379727.586339: sched:sched_switch: prev_comm=ls prev_pid=30482 ...
      :30482 30482 [000] 1379727.589462: sched:sched_switch: prev_comm=ls prev_pid=30482 ...
      
      The last line lost the conversion from tid to comm. If you look at the events
      (perf script -D) you see why - a SAMPLE event is generated after the EXIT:
      
      0 1379727589449774 0x1540b0 [0x38]: PERF_RECORD_EXIT(30482:30482):(30482:30482)
      0 1379727589462497 0x1540e8 [0x80]: PERF_RECORD_SAMPLE(IP, 1): 30482/30482: 0xffffffff816416f1 period: 1 addr: 0
      ... thread: :30482:30482
      
      When perf processes the EXIT event the thread is moved to the dead_threads
      list. When the SAMPLE event is processed no thread exists for the pid so a new
      one is created by machine__findnew_thread.
      
      This patch address the problem by delaying the move to the dead_threads list
      until the tid is re-used (per Adrian's suggestion).
      
      With this patch we get the previous example shows:
      
        ls 30482 [000] 1379727.583037: sched:sched_switch: prev_comm=ls prev_pid=30482 ...
        ls 30482 [000] 1379727.586339: sched:sched_switch: prev_comm=ls prev_pid=30482 ...
        ls 30482 [000] 1379727.589462: sched:sched_switch: prev_comm=ls prev_pid=30482 ...
      
      and
      
        0 1379727589449774 0x1540b0 [0x38]: PERF_RECORD_EXIT(30482:30482):(30482:30482)
        0 1379727589462497 0x1540e8 [0x80]: PERF_RECORD_SAMPLE(IP, 1): 30482/30482: 0xffffffff816416f1 period: 1 addr: 0
        ... thread: ls:30482
      
      v4: per Arnaldo's request add dead flag to thread struct and set when task exits
      
      v3: re-do from a time based check to a delayed move to dead_threads list
      
      v2: Rebased to latest perf/core branch. Changed time comparison to use
          a macro which explicitly shows the time basis
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1376491767-84171-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      236a3bbd
  22. 12 8月, 2013 2 次提交
  23. 08 8月, 2013 3 次提交
  24. 13 7月, 2013 1 次提交
    • G
      perf report/top: Add option to collapse undesired parts of call graph · b21484f1
      Greg Price 提交于
      For example, in an application with an expensive function implemented
      with deeply nested recursive calls, the default call-graph presentation
      is dominated by the different callchains within that function.  By
      ignoring these callees, we can collect the callchains leading into the
      function and compactly identify what to blame for expensive calls.
      
      For example, in this report the callers of garbage_collect() are
      scattered across the tree:
      
        $ perf report -d ruby 2>- | grep -m10 ^[^#]*[a-z]
            22.03%     ruby  [.] gc_mark
                       --- gc_mark
                          |--59.40%-- mark_keyvalue
                          |          st_foreach
                          |          gc_mark_children
                          |          |--99.75%-- rb_gc_mark
                          |          |          rb_vm_mark
                          |          |          gc_mark_children
                          |          |          gc_marks
                          |          |          |--99.00%-- garbage_collect
      
      If we ignore the callees of garbage_collect(), its callers are coalesced:
      
        $ perf report --ignore-callees garbage_collect -d ruby 2>- | grep -m10 ^[^#]*[a-z]
            72.92%     ruby  [.] garbage_collect
                       --- garbage_collect
                           vm_xmalloc
                          |--47.08%-- ruby_xmalloc
                          |          st_insert2
                          |          rb_hash_aset
                          |          |--98.45%-- features_index_add
                          |          |          rb_provide_feature
                          |          |          rb_require_safe
                          |          |          vm_call_method
      Signed-off-by: NGreg Price <price@mit.edu>
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20130623031720.GW22203@biohazard-cafe.mit.edu
      Link: http://lkml.kernel.org/r/20130708115746.GO22203@biohazard-cafe.mit.edu
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      [ remove spaces at beginning of line, reported by Fengguang Wu ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b21484f1