1. 23 1月, 2022 1 次提交
    • I
      perf cpumap: Migrate to libperf cpumap api · 44028699
      Ian Rogers 提交于
      Switch from directly accessing the perf_cpu_map to using the appropriate
      libperf API when possible. Using the API simplifies the job of
      refactoring use of perf_cpu_map.
      Signed-off-by: NIan Rogers <irogers@google.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Bayduraev <alexey.v.bayduraev@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: André Almeida <andrealmeid@collabora.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Dmitriy Vyukov <dvyukov@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: German Gomez <german.gomez@arm.com>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: John Garry <john.garry@huawei.com>
      Cc: Kajol Jain <kjain@linux.ibm.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Miaoqian Lin <linmq006@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Riccardo Mancini <rickyman7@gmail.com>
      Cc: Shunsuke Nakamura <nakamura.shun@fujitsu.com>
      Cc: Song Liu <song@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Stephen Brennan <stephen.s.brennan@oracle.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: Yury Norov <yury.norov@gmail.com>
      Link: http://lore.kernel.org/lkml/20220122045811.3402706-3-irogers@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      44028699
  2. 13 1月, 2022 1 次提交
    • I
      perf cpumap: Give CPUs their own type · 6d18804b
      Ian Rogers 提交于
      A common problem is confusing CPU map indices with the CPU, by wrapping
      the CPU with a struct then this is avoided. This approach is similar to
      atomic_t.
      
      Committer notes:
      
      To make it build with BUILD_BPF_SKEL=1 these files needed the
      conversions to 'struct perf_cpu' usage:
      
        tools/perf/util/bpf_counter.c
        tools/perf/util/bpf_counter_cgroup.c
        tools/perf/util/bpf_ftrace.c
      
      Also perf_env__get_cpu() was removed back in "perf cpumap: Switch
      cpu_map__build_map to cpu function".
      
      Additionally these needed to be fixed for the ARM builds to complete:
      
        tools/perf/arch/arm/util/cs-etm.c
        tools/perf/arch/arm64/util/pmu.c
      Suggested-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NIan Rogers <irogers@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Clark <james.clark@arm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kajol Jain <kjain@linux.ibm.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Clarke <pc@us.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Riccardo Mancini <rickyman7@gmail.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Vineet Singh <vineet.singh@intel.com>
      Cc: coresight@lists.linaro.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: zhengjun.xing@intel.com
      Link: https://lore.kernel.org/r/20220105061351.120843-49-irogers@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6d18804b
  3. 16 12月, 2021 1 次提交
    • G
      perf arch: Support register names from all archs · 83869019
      German Gomez 提交于
      When reading a perf.data file with register values, there is a mismatch
      between the names and the values of the registers because the tool is
      built using only the register names from the local architecture.
      
      Reading a perf.data file that was recorded on ARM64, gives the following
      erroneous output on an X86 machine:
      
        # perf report -i perf_arm64.data -D
        [...]
        24661932634451 0x698 [0x21d0]: PERF_RECORD_SAMPLE(IP, 0x1): 43239/43239: 0xffffc5be8f100f98 period: 1 addr: 0
        ... user regs: mask 0x1ffffffff ABI 64-bit
        .... AX    0x0000ffffd1515817
        .... BX    0x0000ffffd1515480
        .... CX    0x0000aaaadabf6c80
        .... DX    0x000000000000002e
        .... SI    0x0000000040100401
        .... DI    0x0040600200000080
        .... BP    0x0000ffffd1510e10
        .... SP    0x0000000000000000
        .... IP    0x00000000000000dd
        .... FLAGS 0x0000ffffd1510cd0
        .... CS    0x0000000000000000
        .... SS    0x0000000000000030
        .... DS    0x0000ffffa569a208
        .... ES    0x0000000000000000
        .... FS    0x0000000000000000
        .... GS    0x0000000000000000
        .... R8    0x0000aaaad3de9650
        .... R9    0x0000ffffa57397f0
        .... R10   0x0000000000000001
        .... R11   0x0000ffffa57fd000
        .... R12   0x0000ffffd1515817
        .... R13   0x0000ffffd1515480
        .... R14   0x0000aaaadabf6c80
        .... R15   0x0000000000000000
        .... unknown 0x0000000000000001
        .... unknown 0x0000000000000000
        .... unknown 0x0000000000000000
        .... unknown 0x0000000000000000
        .... unknown 0x0000000000000000
        .... unknown 0x0000ffffd1510d90
        .... unknown 0x0000ffffa5739b90
        .... unknown 0x0000ffffd1510d80
        .... XMM0  0x0000ffffa57392c8
         ... thread: perf-exec:43239
         ...... dso: [kernel.kallsyms]
      
      As can be seen, the register names correspond to X86 registers, even
      though the perf.data file was recorded on an ARM64 system. After this
      patch, the output of the command displays the correct register names:
      
        # perf report -i perf_arm64.data -D
        [...]
        24661932634451 0x698 [0x21d0]: PERF_RECORD_SAMPLE(IP, 0x1): 43239/43239: 0xffffc5be8f100f98 period: 1 addr: 0
        ... user regs: mask 0x1ffffffff ABI 64-bit
        .... x0    0x0000ffffd1515817
        .... x1    0x0000ffffd1515480
        .... x2    0x0000aaaadabf6c80
        .... x3    0x000000000000002e
        .... x4    0x0000000040100401
        .... x5    0x0040600200000080
        .... x6    0x0000ffffd1510e10
        .... x7    0x0000000000000000
        .... x8    0x00000000000000dd
        .... x9    0x0000ffffd1510cd0
        .... x10   0x0000000000000000
        .... x11   0x0000000000000030
        .... x12   0x0000ffffa569a208
        .... x13   0x0000000000000000
        .... x14   0x0000000000000000
        .... x15   0x0000000000000000
        .... x16   0x0000aaaad3de9650
        .... x17   0x0000ffffa57397f0
        .... x18   0x0000000000000001
        .... x19   0x0000ffffa57fd000
        .... x20   0x0000ffffd1515817
        .... x21   0x0000ffffd1515480
        .... x22   0x0000aaaadabf6c80
        .... x23   0x0000000000000000
        .... x24   0x0000000000000001
        .... x25   0x0000000000000000
        .... x26   0x0000000000000000
        .... x27   0x0000000000000000
        .... x28   0x0000000000000000
        .... x29   0x0000ffffd1510d90
        .... lr    0x0000ffffa5739b90
        .... sp    0x0000ffffd1510d80
        .... pc    0x0000ffffa57392c8
         ... thread: perf-exec:43239
         ...... dso: [kernel.kallsyms]
      
      Tester comments:
      
      Athira reports:
      
      "Looks good to me. Tested this patchset in powerpc by capturing regs in
      powerpc and doing perf report to read the data from x86."
      Reported-by: NAlexandre Truong <alexandre.truong@arm.com>
      Reviewed-by: NAthira Jajeev <atrajeev@linux.vnet.ibm.com>
      Signed-off-by: NGerman Gomez <german.gomez@arm.com>
      Tested-by: NAthira Jajeev <atrajeev@linux.vnet.ibm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: John Garry <john.garry@huawei.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Will Deacon <will@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-csky@vger.kernel.org
      Cc: linux-riscv@lists.infradead.org
      Link: https://lore.kernel.org/r/20211207180653.1147374-4-german.gomez@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      83869019
  4. 07 12月, 2021 1 次提交
  5. 03 9月, 2021 1 次提交
  6. 07 7月, 2021 1 次提交
    • K
      perf script python: Fix buffer size to report iregs in perf script · dea8cfcc
      Kajol Jain 提交于
      Commit 48a1f565 ("perf script python: Add more PMU fields to
      event handler dict") added functionality to report fields like weight,
      iregs, uregs etc via perf report.  That commit predefined buffer size to
      512 bytes to print those fields.
      
      But in PowerPC, since we added extended regs support in:
      
        068aeea3 ("perf powerpc: Support exposing Performance Monitor Counter SPRs as part of extended regs")
        d735599a ("powerpc/perf: Add extended regs support for power10 platform")
      
      Now iregs can carry more bytes of data and this predefined buffer size
      can result to data loss in perf script output.
      
      This patch resolves this issue by making the buffer size dynamic, based
      on the number of registers needed to print. It also changes the
      regs_map() return type from int to void, as it is not being used by the
      set_regs_in_dict(), its only caller.
      
      Fixes: 068aeea3 ("perf powerpc: Support exposing Performance Monitor Counter SPRs as part of extended regs")
      Signed-off-by: NKajol Jain <kjain@linux.ibm.com>
      Tested-by: NNageswara R Sastry <rnsastry@linux.ibm.com>
      Cc: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Cc: Paul Clarke <pc@us.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lore.kernel.org/lkml/20210628062341.155839-1-kjain@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dea8cfcc
  7. 01 6月, 2021 3 次提交
  8. 25 5月, 2021 9 次提交
  9. 24 3月, 2021 1 次提交
  10. 03 11月, 2020 1 次提交
    • A
      perf scripting python: Avoid declaring function pointers with a visibility attribute · d0e7b0c7
      Arnaldo Carvalho de Melo 提交于
      To avoid this:
      
        util/scripting-engines/trace-event-python.c: In function 'python_start_script':
        util/scripting-engines/trace-event-python.c:1595:2: error: 'visibility' attribute ignored [-Werror=attributes]
         1595 |  PyMODINIT_FUNC (*initfunc)(void);
              |  ^~~~~~~~~~~~~~
      
      That started breaking when building with PYTHON=python3 and these gcc
      versions (I haven't checked with the clang ones, maybe it breaks there
      as well):
      
        # export PERF_TARBALL=http://192.168.86.5/perf/perf-5.9.0.tar.xz
        # dm  fedora:33 fedora:rawhide
           1   107.80 fedora:33         : Ok   gcc (GCC) 10.2.1 20201005 (Red Hat 10.2.1-5), clang version 11.0.0 (Fedora 11.0.0-1.fc33)
           2    92.47 fedora:rawhide    : Ok   gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6), clang version 11.0.0 (Fedora 11.0.0-1.fc34)
        #
      
      Avoid that by ditching that 'initfunc' function pointer with its:
      
          #define Py_EXPORTED_SYMBOL _attribute_ ((visibility ("default")))
          #define PyMODINIT_FUNC Py_EXPORTED_SYMBOL PyObject*
      
      And just call PyImport_AppendInittab() at the end of the ifdef python3
      block with the functions that were being attributed to that initfunc.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d0e7b0c7
  11. 14 10月, 2020 2 次提交
  12. 06 5月, 2020 1 次提交
  13. 03 4月, 2020 1 次提交
  14. 10 3月, 2020 1 次提交
    • K
      perf tools: Add hw_idx in struct branch_stack · 42bbabed
      Kan Liang 提交于
      The low level index of raw branch records for the most recent branch can
      be recorded in a sample with PERF_SAMPLE_BRANCH_HW_INDEX
      branch_sample_type. Extend struct branch_stack to support it.
      
      However, if the PERF_SAMPLE_BRANCH_HW_INDEX is not applied, only nr and
      entries[] will be output by kernel. The pointer of entries[] could be
      wrong, since the output format is different with new struct
      branch_stack.  Add a variable no_hw_idx in struct perf_sample to
      indicate whether the hw_idx is output.  Add get_branch_entry() to return
      corresponding pointer of entries[0].
      
      To make dummy branch sample consistent as new branch sample, add hw_idx
      in struct dummy_branch_stack for cs-etm and intel-pt.
      
      Apply the new struct branch_stack for synthetic events as well.
      
      Extend test case sample-parsing to support new struct branch_stack.
      
      Committer notes:
      
      Renamed get_branch_entries() to perf_sample__branch_entries() to have
      proper namespacing and pave the way for this to be moved to libperf,
      eventually.
      
      Add 'static' to that inline as it is in a header.
      
      Add 'hw_idx' to 'struct dummy_branch_stack' in cs-etm.c to fix the build
      on arm64.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pavel Gerasimov <pavel.gerasimov@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vitaly Slobodskoy <vitaly.slobodskoy@intel.com>
      Link: http://lore.kernel.org/lkml/20200228163011.19358-2-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      42bbabed
  15. 26 11月, 2019 1 次提交
  16. 12 11月, 2019 2 次提交
  17. 05 11月, 2019 1 次提交
  18. 18 10月, 2019 1 次提交
  19. 20 9月, 2019 2 次提交
  20. 01 9月, 2019 1 次提交
  21. 30 8月, 2019 1 次提交
  22. 23 8月, 2019 2 次提交
  23. 30 7月, 2019 4 次提交