1. 06 5月, 2020 2 次提交
  2. 18 4月, 2020 1 次提交
    • K
      perf header: Support CPU PMU capabilities · 6f91ea28
      Kan Liang 提交于
      To stitch LBR call stack, the max LBR information is required. So the
      CPU PMU capabilities information has to be stored in perf header.
      
      Add a new feature HEADER_CPU_PMU_CAPS for CPU PMU capabilities.
      Retrieve all CPU PMU capabilities, not just max LBR information.
      
      Add variable max_branches to facilitate future usage.
      
      Committer testing:
      
        # ls -la /sys/devices/cpu/caps/
        total 0
        drwxr-xr-x. 2 root root    0 Apr 17 10:53 .
        drwxr-xr-x. 6 root root    0 Apr 17 07:02 ..
        -r--r--r--. 1 root root 4096 Apr 17 10:53 max_precise
        #
        # cat /sys/devices/cpu/caps/max_precise
        0
        # perf record sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.033 MB perf.data (7 samples) ]
        #
        # perf report --header-only | egrep 'cpu(desc|.*capabilities)'
        # cpudesc : AMD Ryzen 5 3600X 6-Core Processor
        # cpu pmu capabilities: max_precise=0
        #
      
      And then on an Intel machine:
      
        $ ls -la /sys/devices/cpu/caps/
        total 0
        drwxr-xr-x. 2 root root    0 Apr 17 10:51 .
        drwxr-xr-x. 6 root root    0 Apr 17 10:04 ..
        -r--r--r--. 1 root root 4096 Apr 17 11:37 branches
        -r--r--r--. 1 root root 4096 Apr 17 10:51 max_precise
        -r--r--r--. 1 root root 4096 Apr 17 11:37 pmu_name
        $ cat /sys/devices/cpu/caps/max_precise
        3
        $ cat /sys/devices/cpu/caps/branches
        32
        $ cat /sys/devices/cpu/caps/pmu_name
        skylake
        $ perf record sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.001 MB perf.data (8 samples) ]
        $ perf report --header-only | egrep 'cpu(desc|.*capabilities)'
        # cpudesc : Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
        # cpu pmu capabilities: branches=32, max_precise=3, pmu_name=skylake
        $
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.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/20200319202517.23423-3-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6f91ea28
  3. 10 3月, 2020 1 次提交
    • K
      perf header: Add check for unexpected use of reserved membrs in event attr · 277ce1ef
      Kan Liang 提交于
      The perf.data may be generated by a newer version of perf tool, which
      support new input bits in attr, e.g. new bit for branch_sample_type.
      
      The perf.data may be parsed by an older version of perf tool later.  The
      old perf tool may parse the perf.data incorrectly. There is no warning
      message for this case.
      
      Current perf header never check for unknown input bits in attr.
      
      When read the event desc from header, check the stored event attr.  The
      reserved bits, sample type, read format and branch sample type will be
      checked.
      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://lkml.kernel.org/r/20200228163011.19358-4-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      277ce1ef
  4. 15 1月, 2020 1 次提交
    • M
      perf header: Use last modification time for timestamp · 8af19d66
      Michael Petlan 提交于
      Using .st_ctime clobbers the timestamp information in perf report header
      whenever any operation is done with the file. Even tar-ing and untar-ing
      the perf.data file (which preserves the file last modification timestamp)
      doesn't prevent that:
      
          [Michael@Diego tmp]$ ls -l perf.data
      ->	-rw-------. 1 Michael Michael 169888 Dec  2 15:23 perf.data
      
      	[Michael@Diego tmp]$ perf report --header-only
      	# ========
      ->	# captured on    : Mon Dec  2 15:23:42 2019
      	 [...]
      
      	[Michael@Diego tmp]$ tar c perf.data | xz > perf.data.tar.xz
      	[Michael@Diego tmp]$ mkdir aaa
      	[Michael@Diego tmp]$ cd aaa
      	[Michael@Diego aaa]$ xzcat ../perf.data.tar.xz | tar x
      	[Michael@Diego aaa]$ ls -l -a
      	total 172
      	drwxrwxr-x. 2 Michael Michael     23 Jan 14 11:26 .
      	drwxrwxr-x. 6 Michael Michael   4096 Jan 14 11:26 ..
      ->	-rw-------. 1 Michael Michael 169888 Dec  2 15:23 perf.data
      
      	[Michael@Diego aaa]$ perf report --header-only
      	# ========
      ->	# captured on    : Tue Jan 14 11:26:16 2020
      	 [...]
      
      When using .st_mtime instead, correct information is printed:
      
      	[Michael@Diego aaa]$ ~/acme/tools/perf/perf report --header-only
      	# ========
      ->	# captured on    : Mon Dec  2 15:23:42 2019
      	 [...]
      Signed-off-by: NMichael Petlan <mpetlan@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      LPU-Reference: 20200114104236.31555-1-mpetlan@redhat.com
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8af19d66
  5. 11 12月, 2019 2 次提交
  6. 15 10月, 2019 1 次提交
  7. 26 9月, 2019 1 次提交
  8. 25 9月, 2019 5 次提交
  9. 21 9月, 2019 1 次提交
    • J
      perf tools: Fix segfault in cpu_cache_level__read() · 0216234c
      Jiri Olsa 提交于
      We release wrong pointer on error path in cpu_cache_level__read
      function, leading to segfault:
      
        (gdb) r record ls
        Starting program: /root/perf/tools/perf/perf record ls
        ...
        [ perf record: Woken up 1 times to write data ]
        double free or corruption (out)
      
        Thread 1 "perf" received signal SIGABRT, Aborted.
        0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
        (gdb) bt
        #0  0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
        #1  0x00007ffff7443bac in abort () from /lib64/power9/libc.so.6
        #2  0x00007ffff74af8bc in __libc_message () from /lib64/power9/libc.so.6
        #3  0x00007ffff74b92b8 in malloc_printerr () from /lib64/power9/libc.so.6
        #4  0x00007ffff74bb874 in _int_free () from /lib64/power9/libc.so.6
        #5  0x0000000010271260 in __zfree (ptr=0x7fffffffa0b0) at ../../lib/zalloc..
        #6  0x0000000010139340 in cpu_cache_level__read (cache=0x7fffffffa090, cac..
        #7  0x0000000010143c90 in build_caches (cntp=0x7fffffffa118, size=<optimiz..
        ...
      
      Releasing the proper pointer.
      
      Fixes: 720e98b5 ("perf tools: Add perf data cache feature")
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org: # v4.6+
      Link: http://lore.kernel.org/lkml/20190912105235.10689-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0216234c
  10. 20 9月, 2019 3 次提交
  11. 01 9月, 2019 1 次提交
  12. 30 8月, 2019 3 次提交
  13. 29 8月, 2019 3 次提交
  14. 14 8月, 2019 1 次提交
    • T
      perf record: Support aarch64 random socket_id assignment · 0a4d8fb2
      Tan Xiaojun 提交于
      Same as in the commit 01766229 ("perf record: Support s390 random
      socket_id assignment"), aarch64 also have this problem.
      
      Without this fix:
      
        [root@localhost perf]# ./perf report --header -I -v
        ...
        socket_id number is too big.You may need to upgrade the perf tool.
      
        # ========
        # captured on    : Thu Aug  1 22:58:38 2019
        # header version : 1
        ...
        # Core ID and Socket ID information is not available
        ...
      
      With this fix:
        [root@localhost perf]# ./perf report --header -I -v
        ...
        cpumask list: 0-31
        cpumask list: 32-63
        cpumask list: 64-95
        cpumask list: 96-127
      
        # ========
        # captured on    : Thu Aug  1 22:58:38 2019
        # header version : 1
        ...
        # CPU 0: Core ID 0, Socket ID 36
        # CPU 1: Core ID 1, Socket ID 36
        ...
        # CPU 126: Core ID 126, Socket ID 8442
        # CPU 127: Core ID 127, Socket ID 8442
        ...
      Signed-off-by: NTan Xiaojun <tanxiaojun@huawei.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
      Link: http://lkml.kernel.org/r/1564717737-21602-1-git-send-email-tanxiaojun@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a4d8fb2
  15. 30 7月, 2019 13 次提交
  16. 29 7月, 2019 1 次提交
    • N
      perf header: Fix use of unitialized value warning · 20f9781f
      Numfor Mbiziwo-Tiapo 提交于
      When building our local version of perf with MSAN (Memory Sanitizer) and
      running the perf record command, MSAN throws a use of uninitialized
      value warning in "tools/perf/util/util.c:333:6".
      
      This warning stems from the "buf" variable being passed into "write".
      It originated as the variable "ev" with the type union perf_event*
      defined in the "perf_event__synthesize_attr" function in
      "tools/perf/util/header.c".
      
      In the "perf_event__synthesize_attr" function they allocate space with a malloc
      call using ev, then go on to only assign some of the member variables before
      passing "ev" on as a parameter to the "process" function therefore "ev"
      contains uninitialized memory. Changing the malloc call to zalloc to initialize
      all the members of "ev" which gets rid of the warning.
      
      To reproduce this warning, build perf by running:
      make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory\
       -fsanitize-memory-track-origins"
      
      (Additionally, llvm might have to be installed and clang might have to
      be specified as the compiler - export CC=/usr/bin/clang)
      
      then running:
      tools/perf/perf record -o - ls / | tools/perf/perf --no-pager annotate\
       -i - --stdio
      
      Please see the cover letter for why false positive warnings may be
      generated.
      Signed-off-by: NNumfor Mbiziwo-Tiapo <nums@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Drayton <mbd@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190724234500.253358-2-nums@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      20f9781f