1. 15 9月, 2015 1 次提交
  2. 14 9月, 2015 1 次提交
    • K
      perf report: Introduce --socket-filter option · 21394d94
      Kan Liang 提交于
      Introduce --socket-filter option for 'perf report' to only show entries
      for a processor socket that match this filter.
      
        $ perf report --socket-filter 1 --stdio
        # To display the perf.data header info, please use --header/--header-only options.
        #
        # Total Lost Samples: 0
        #
        # Samples: 752  of event 'cycles'
        # Event count (approx.): 350995599
        # Processor Socket: 1
        #
        # Overhead  Command    Shared Object     Symbol
        # ........  .........  ................  .................................
        #
            97.02%  test       test              [.] plusB_c
             0.97%  test       test              [.] plusA_c
             0.23%  swapper    [kernel.vmlinux]  [k] acpi_idle_do_entry
             0.09%  rcu_sched  [kernel.vmlinux]  [k] dyntick_save_progress_counter
             0.01%  swapper    [kernel.vmlinux]  [k] task_waking_fair
             0.00%  swapper    [kernel.vmlinux]  [k] run_timer_softirq
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1441377946-44429-3-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      21394d94
  3. 13 8月, 2015 1 次提交
    • K
      perf report: Show call graph from reference events · 9e207ddf
      Kan Liang 提交于
      Introduce --show-ref-call-graph for perf report to print reference
      callgraph for no callgraph event.
      
      Here is an example.
      
       perf report --show-ref-call-graph --stdio
      
       # To display the perf.data header info, please use
       --header/--header-only options.
       #
       #
       # Total Lost Samples: 0
       #
       # Samples: 5  of event 'cpu/cpu-cycles,call-graph=fp/'
       # Event count (approx.): 144985
       #
       # Children      Self  Command  Shared Object     Symbol
       # ........  ........  .......  ................  ........................................
       #
          72.30%     0.00%  sleep    [kernel.vmlinux]  [k] entry_SYSCALL_64_fastpath
                    |
                    ---entry_SYSCALL_64_fastpath
                       |
                       |--22.62%-- __GI___libc_nanosleep
                        --77.38%-- [...]
      
      ......
      
       # Samples: 6  of event 'cpu/instructions,call-graph=no/', show reference callgraph
       # Event count (approx.): 172780
       #
       # Children      Self  Command  Shared Object     Symbol
       # ........  ........  .......  ................  ........................................
       #
          73.16%     0.00%  sleep    [kernel.vmlinux]  [k] entry_SYSCALL_64_fastpath
                    |
                    ---entry_SYSCALL_64_fastpath
                       |
                       |--31.44%-- __GI___libc_nanosleep
                        --68.56%-- [...]
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1439289050-40510-3-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9e207ddf
  4. 10 8月, 2015 1 次提交
  5. 07 8月, 2015 2 次提交
  6. 02 7月, 2015 1 次提交
  7. 26 6月, 2015 1 次提交
    • L
      perf symbols: Check access permission when reading symbol files · 36c8bb56
      Li Zhang 提交于
      There 2 problems when reading symbols files:
      
      *  It doesn't report any errors even if when users specify symbol
         files which don't exist with --kallsyms or --vmlinux. The result
         just shows the address without symbols, which is not what is expected.
         So it's better to report errors and exit the program.
      
      *  When using command perf report --kallsyms=/proc/kallsyms with a
         non-root user, symbols are resolved. Then select one symbol and
         annotate it, it reports the error as the following:
         Can't annotate __clear_user: No vmlinux file with build id xxx was
         found.
      
         The problem is caused by reading /proc/kcore without access permission.
         /proc/kcore requires CAP_SYS_RAWIO capability to access, so it needs to
         change access permission to allow a specific user to read /proc/kcore or
         use root to execute the perf command.
      
      This patch is to report errors when symbol files specified by users
      don't exist. And check access permission of /proc/kcore when reading it.
      Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1434704253-2632-1-git-send-email-zhlcindy@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      36c8bb56
  8. 11 6月, 2015 1 次提交
    • H
      perf tools: Fix build failure on 32-bit arch · 6ba29c2f
      He Kuang 提交于
      Failed in 32bit arch build like this:
      
          CC       /opt/h00206996/output/perf/arm32/builtin-record.o
        util/session.c: In function ‘perf_session__warn_about_errors’:
        util/session.c:1304:9: error: format ‘%lu’ expects argument of type ‘long unsigned int’,
                               but argument 2 has type ‘long long unsigned int’ [-Werror=format=]
      
        builtin-report.c: In function ‘perf_evlist__tty_browse_hists’:
        builtin-report.c:323:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’,
                                but argument 3 has type ‘u64’ [-Werror=format=]
      
      Replace %lu format strings in warning message with PRIu64 for u64
      'total_lost_samples' to fix this problem.
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1434026664-71642-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6ba29c2f
  9. 07 6月, 2015 1 次提交
    • K
      perf tools: handle PERF_RECORD_LOST_SAMPLES · c4937a91
      Kan Liang 提交于
      This patch modifies the perf tool to handle the new RECORD type,
      PERF_RECORD_LOST_SAMPLES.
      
      The number of lost-sample events is stored in
      .nr_events[PERF_RECORD_LOST_SAMPLES]. The exact number of samples
      which the kernel dropped is stored in total_lost_samples.
      
      When the percentage of dropped samples is greater than 5%, a warning
      is printed.
      
      Here are some examples:
      
      Eg 1, Recording different frequently-occurring events is safe with the
            patch. Only a very low drop rate is associated with such actions.
      
      $ perf record -e '{cycles:p,instructions:p}' -c 20003 --no-time ~/tchain ~/tchain
      
      $ perf report -D | tail
                SAMPLE events:     120243
                 MMAP2 events:          5
          LOST_SAMPLES events:         24
        FINISHED_ROUND events:         15
      cycles:p stats:
                 TOTAL events:      59348
                SAMPLE events:      59348
      instructions:p stats:
                 TOTAL events:      60895
                SAMPLE events:      60895
      
      $ perf report --stdio --group
       # To display the perf.data header info, please use --header/--header-only options.
       #
       #
       # Total Lost Samples: 24
       #
       # Samples: 120K of event 'anon group { cycles:p, instructions:p }'
       # Event count (approx.): 24048600000
       #
       #         Overhead  Command      Shared Object     Symbol
       # ................  ...........  ................
       ..................................
       #
          99.74%  99.86%  tchain_edit  tchain_edit       [.] f3
           0.09%   0.02%  tchain_edit  tchain_edit       [.] f2
           0.04%   0.00%  tchain_edit  [kernel.vmlinux]  [k] ixgbe_read_reg
      
      Eg 2, Recording the same thing multiple times can lead to high drop
            rate, but it is not a useful configuration.
      
      $ perf record -e '{cycles:p,cycles:p}' -c 20003 --no-time ~/tchain
      Warning: Processed 600592 samples and lost 99.73% samples!
      [perf record: Woken up 148 times to write data]
      [perf record: Captured and wrote 36.922 MB perf.data (1206322 samples)]
      [perf record: Woken up 1 times to write data]
      [perf record: Captured and wrote 0.121 MB perf.data (1629 samples)]
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@infradead.org
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1431285195-14269-9-git-send-email-kan.liang@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c4937a91
  10. 27 5月, 2015 1 次提交
  11. 12 5月, 2015 2 次提交
  12. 09 5月, 2015 1 次提交
    • A
      perf machine: Protect the machine->threads with a rwlock · b91fc39f
      Arnaldo Carvalho de Melo 提交于
      In addition to using refcounts for the struct thread lifetime
      management, we need to protect access to machine->threads from
      concurrent access.
      
      That happens in 'perf top', where a thread processes events, inserting
      and deleting entries from that rb_tree while another thread decays
      hist_entries, that end up dropping references and ultimately deleting
      threads from the rb_tree and releasing its resources when no further
      hist_entry (or other data structures, like in 'perf sched') references
      it.
      
      So the rule is the same for refcounts + protected trees in the kernel,
      get the tree lock, find object, bump the refcount, drop the tree lock,
      return, use object, drop the refcount if no more use of it is needed,
      keep it if storing it in some other data structure, drop when releasing
      that data structure.
      
      I.e. pair "t = machine__find(new)_thread()" with a "thread__put(t)", and
      "perf_event__preprocess_sample(&al)" with "addr_location__put(&al)".
      
      The addr_location__put() one is because as we return references to
      several data structures, we may end up adding more reference counting
      for the other data structures and then we'll drop it at
      addr_location__put() time.
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-bs9rt4n0jw3hi9f3zxyy3xln@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b91fc39f
  13. 04 5月, 2015 1 次提交
  14. 01 5月, 2015 1 次提交
  15. 08 4月, 2015 1 次提交
  16. 25 3月, 2015 1 次提交
  17. 24 3月, 2015 1 次提交
  18. 20 3月, 2015 1 次提交
  19. 11 3月, 2015 1 次提交
  20. 28 2月, 2015 1 次提交
    • H
      perf report: Fix branch stack mode cannot be set · fefd2d96
      He Kuang 提交于
      When perf.data file is obtained using 'perf record -b', perf report
      should use branch stack mode to generate output. But this function is
      broken by improper comparison between boolean and constant -1.
      
      before this patch:
      
        $ perf report -b -i perf.data
        Samples: 16  of event 'cycles', Event count (approx.): 3171896
        Overhead  Command  Shared Object      Symbol
          13.59%  ls       [kernel.kallsyms]  [k] prio_tree_remove
          13.16%  ls       [kernel.kallsyms]  [k] change_pte_range
          12.09%  ls       [kernel.kallsyms]  [k] page_fault
          12.02%  ls       [kernel.kallsyms]  [k] zap_pte_range
        ...
      
      after this patch:
      
        $ perf report -b -i perf.data
        Samples: 256  of event 'cycles', Event count (approx.): 256
        Overhead  Command  Source Shared Object  Source Symbol                               Target Shared Object  Target Symbol
           9.38%  ls       [unknown]             [k] 0000000000000000                        [unknown]             [k] 0000000000000000
           6.25%  ls       libc-2.19.so          [.] _dl_addr                                libc-2.19.so          [.] _dl_addr
           6.25%  ls       [kernel.kallsyms]     [k] zap_pte_range                           [kernel.kallsyms]     [k] zap_pte_range
           6.25%  ls       [kernel.kallsyms]     [k] change_pte_range                        [kernel.kallsyms]     [k] change_pte_range
           0.39%  ls       [kernel.kallsyms]     [k] prio_tree_remove                        [kernel.kallsyms]     [k] prio_tree_remove
        ...
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1423967617-28879-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fefd2d96
  21. 19 2月, 2015 1 次提交
    • K
      perf tools: Enable LBR call stack support · aad2b21c
      Kan Liang 提交于
      Currently, there are two call chain recording options, fp and dwarf.
      
      Haswell has a new feature that utilizes the existing LBR facility to
      record call chains. Kernel side LBR support code provides this as a
      third option to record call chains. This patch enables the lbr call
      stack support on the tooling side.
      
      LBR call stack has some limitations:
      
       - It reuses current LBR facility, so LBR call stack and branch record
         can not be enabled at the same time.
      
       - It is only available for user-space callchains.
      
      However, it also offers some advantages:
      
       - LBR call stack can work on user apps which don't have frame-pointers
         or dwarf debug info compiled. It is a good alternative when nothing
         else works.
      Tested-by: NJiri Olsa <jolsa@kernel.org>
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Cody P Schafer <cody@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Jacob Shin <jacob.w.shin@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masanari Iida <standby24x7@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Rodrigo Campos <rodrigo@sdfg.com.ar>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1420482185-29830-2-git-send-email-kan.liang@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      aad2b21c
  22. 22 1月, 2015 1 次提交
  23. 23 12月, 2014 1 次提交
  24. 02 12月, 2014 3 次提交
    • A
      perf report: In branch stack mode use address history sorting · 09a6a1b0
      Andi Kleen 提交于
      Enable CCKEY_ADDRESS address history sorting with --branch-history.
      This makes get_srcline display the source lines correctly, otherwise all
      history entries for a function a hunked into one.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Link: http://lkml.kernel.org/r/1416275935-20971-1-git-send-email-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      09a6a1b0
    • A
      perf report: Add --branch-history option · fa94c36c
      Andi Kleen 提交于
      Add a --branch-history option to perf report that changes all the
      settings necessary for using the branches in callstacks.
      
      This is just a short cut to make this nicer to use, it does not enable
      any functionality by itself.
      
      v2: Change sort order. Rename option to --branch-history to
          be less confusing.
      v3: Updates
      v4: Fix conflict with newer perf base
      v5: Port to latest tip
      v6: Add more comments. Remove CCKEY_ADDRESS setting. Remove
          unnecessary branch_mode setting. Use a boolean.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1415844328-4884-5-git-send-email-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fa94c36c
    • A
      perf callchain: Support handling complete branch stacks as histograms · 8b7bad58
      Andi Kleen 提交于
      Currently branch stacks can be only shown as edge histograms for
      individual branches. I never found this display particularly useful.
      
      This implements an alternative mode that creates histograms over
      complete branch traces, instead of individual branches, similar to how
      normal callgraphs are handled. This is done by putting it in front of
      the normal callgraph and then using the normal callgraph histogram
      infrastructure to unify them.
      
      This way in complex functions we can understand the control flow that
      lead to a particular sample, and may even see some control flow in the
      caller for short functions.
      
      Example (simplified, of course for such simple code this is usually not
      needed), please run this after the whole patchkit is in, as at this
      point in the patch order there is no --branch-history, that will be
      added in a patch after this one:
      
      tcall.c:
      
      volatile a = 10000, b = 100000, c;
      
      __attribute__((noinline)) f2()
      {
      	c = a / b;
      }
      
      __attribute__((noinline)) f1()
      {
      	f2();
      	f2();
      }
      main()
      {
      	int i;
      	for (i = 0; i < 1000000; i++)
      		f1();
      }
      
      % perf record -b -g ./tsrc/tcall
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.044 MB perf.data (~1923 samples) ]
      % perf report --no-children --branch-history
      ...
          54.91%  tcall.c:6  [.] f2                      tcall
                  |
                  |--65.53%-- f2 tcall.c:5
                  |          |
                  |          |--70.83%-- f1 tcall.c:11
                  |          |          f1 tcall.c:10
                  |          |          main tcall.c:18
                  |          |          main tcall.c:18
                  |          |          main tcall.c:17
                  |          |          main tcall.c:17
                  |          |          f1 tcall.c:13
                  |          |          f1 tcall.c:13
                  |          |          f2 tcall.c:7
                  |          |          f2 tcall.c:5
                  |          |          f1 tcall.c:12
                  |          |          f1 tcall.c:12
                  |          |          f2 tcall.c:7
                  |          |          f2 tcall.c:5
                  |          |          f1 tcall.c:11
                  |          |
                  |           --29.17%-- f1 tcall.c:12
                  |                     f1 tcall.c:12
                  |                     f2 tcall.c:7
                  |                     f2 tcall.c:5
                  |                     f1 tcall.c:11
                  |                     f1 tcall.c:10
                  |                     main tcall.c:18
                  |                     main tcall.c:18
                  |                     main tcall.c:17
                  |                     main tcall.c:17
                  |                     f1 tcall.c:13
                  |                     f1 tcall.c:13
                  |                     f2 tcall.c:7
                  |                     f2 tcall.c:5
                  |                     f1 tcall.c:12
      
      The default output is unchanged.
      
      This is only implemented in perf report, no change to record or anywhere
      else.
      
      This adds the basic code to report:
      
      - add a new "branch" option to the -g option parser to enable this mode
      - when the flag is set include the LBR into the callstack in machine.c.
      
      The rest of the history code is unchanged and doesn't know the
      difference between LBR entry and normal call entry.
      
      - detect overlaps with the callchain
      - remove small loop duplicates in the LBR
      
      Current limitations:
      
      - The LBR flags (mispredict etc.) are not shown in the history
      and LBR entries have no special marker.
      - It would be nice if annotate marked the LBR entries somehow
      (e.g. with arrows)
      
      v2: Various fixes.
      v3: Merge further patches into this one. Fix white space.
      v4: Improve manpage. Address review feedback.
      v5: Rename functions. Better error message without -g. Fix crash without
          -b.
      v6: Rebase
      v7: Rebase. Use NO_ENTRY in memset.
      v8: Port to latest tip. Move add_callchain_ip to separate
          patch. Skip initial entries in callchain. Minor cleanups.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1415844328-4884-3-git-send-email-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8b7bad58
  25. 16 10月, 2014 1 次提交
  26. 15 10月, 2014 1 次提交
    • A
      perf tools: Remove hists from evsel · a635fc51
      Arnaldo Carvalho de Melo 提交于
      Now tools that deals want to have an hists per evsel need to call
      hists__init() before creating any evsels, which can be as early as when
      parsing the command line, so do it before calling parse_options().
      
      The current tools using hists/hist_entries are report, top and annotate,
      change them to request per evsel hists.
      
      This is in preparation for making evsels usable by 3rd party tools, that
      not necessarily live in perf's source code repository.
      Acked-by: NBorislav Petkov <bp@suse.de>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jean Pihet <jean.pihet@linaro.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      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-usjx2la743f10ippj7p1b20x@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a635fc51
  27. 14 10月, 2014 1 次提交
    • A
      perf session: Remove last reference to hists struct · 2a1731fb
      Arnaldo Carvalho de Melo 提交于
      Now perf_session doesn't require that the evsels in its evlist are hists
      containing ones.
      
      Tools that are hists based and want to do per evsel events_stats
      updates, if at some point this turns into a necessity, should do it in
      the tool specific code, keeping the session class hists agnostic.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jean Pihet <jean.pihet@linaro.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      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-cli1bgwpo82mdikuhy3djsuy@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2a1731fb
  28. 10 10月, 2014 1 次提交
    • A
      perf evsel: Add hists helper · 4ea062ed
      Arnaldo Carvalho de Melo 提交于
      Not all tools need a hists instance per perf_evsel, so lets pave the way
      to remove evsel->hists while leaving a way to access the hists from a
      specially allocated evsel, one that comes with space at the end where
      lives the evsel.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jean Pihet <jean.pihet@linaro.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      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-qlktkhe31w4mgtbd84035sr2@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4ea062ed
  29. 26 9月, 2014 1 次提交
  30. 18 9月, 2014 1 次提交
  31. 14 8月, 2014 2 次提交
    • N
      perf report: Set proper sort__mode for the branch option · edd114e2
      naota@elisp.net 提交于
      When you specify "--branch-stack"("-b" for short) or
      "--no-branch-stack", "branch_mode" variable is set to 1 or 0
      respectively. However, the code is just checking if the variable is -1
      or not, ignoring "branch_mode == 1" case. Thus "perf report -b" dose not
      show its result with the branch sorted mode. This patch fix the problem.
      Signed-off-by: NNaohiro Aota <naota@elisp.net>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/87y4v1fylq.fsf@elisp.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      edd114e2
    • N
      perf tools: Check recorded kernel version when finding vmlinux · 0a7e6d1b
      Namhyung Kim 提交于
      Currently vmlinux_path__init() only tries to find vmlinux file from
      current directory, /boot and some canonical directories with version
      number of the running kernel.  This can be a problem when reporting old
      data recorded on a kernel version not running currently.
      
      We can use --symfs option for this but it's annoying for user to do it
      always.  As we already have the info in the perf.data file, it can be
      changed to use it for the search automatically.
      
      Before:
      
        $ perf report
        ...
        # Samples: 4K of event 'cpu-clock'
        # Event count (approx.): 1067250000
        #
        # Overhead  Command     Shared Object      Symbol
        # ........  ..........  .................  ..............................
            71.87%     swapper  [kernel.kallsyms]  [k] recover_probed_instruction
      
      After:
      
        # Overhead  Command     Shared Object      Symbol
        # ........  ..........  .................  ....................
            71.87%     swapper  [kernel.kallsyms]  [k] native_safe_halt
      
      This requires to change signature of symbol__init() to receive struct
      perf_session_env *.
      Reported-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1407825645-24586-14-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a7e6d1b
  32. 12 8月, 2014 2 次提交
  33. 01 6月, 2014 2 次提交