Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 10月, 2020 2 次提交
  3. 13 8月, 2020 2 次提交
    • J
      perf tools: Fix module symbol processing · b2fe96a3
      由 Jiri Olsa 提交于 
      The 'dso->kernel' condition is true also for kernel modules now,
and there are several places that were omited by the initial change:

  - we need to identify modules separately in dso__process_kernel_symbol
  - we need to set 'dso->kernel' for module from buildid table
  - there's no need to use 'dso->kernel || kmodule' in one condition

Committer testing:

Before:

  # perf test -v object
  <SNIP>
  Objdump command is: objdump -z -d --start-address=0xffffffff813e682f --stop-address=0xffffffff813e68af /usr/lib/debug/lib/modules/5.7.14-200.fc32.x86_64/vmlinux
  Bytes read match those read by objdump
  Reading object code for memory address: 0xffffffffc02dc257
  File is: /lib/modules/5.7.14-200.fc32.x86_64/kernel/arch/x86/crypto/crc32c-intel.ko.xz
  On file address is: 0xffffffffc02dc2e7
  dso__data_read_offset failed
  test child finished with -1
  ---- end ----
  Object code reading: FAILED!
  #

After:

  # perf test object
  26: Object code reading                                   : Ok
  # perf test object
  26: Object code reading                                   : Ok
  # perf test object
  26: Object code reading                                   : Ok
  # perf test object
  26: Object code reading                                   : Ok
  # perf test object
  26: Object code reading                                   : Ok
  #

Fixes: 02213cec ("perf maps: Mark module DSOs with kernel type")
Reported-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      b2fe96a3
    • J
      perf tools: Rename 'enum dso_kernel_type' to 'enum dso_space_type' · 1c695c88
      由 Jiri Olsa 提交于 
      Rename enum dso_kernel_type to enum dso_space_type, which seems like
better fit.

Committer notes:

This is used with 'struct dso'->kernel, which once was a boolean, so
DSO_SPACE__USER is zero, !zero means some sort of kernel space, be it
the host kernel space or a guest kernel space.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1c695c88
  5. 06 8月, 2020 2 次提交
    • J
      perf tools: Move clockid_res_ns under clock struct · 9d88a1a1
      由 Jiri Olsa 提交于 
      Move the clockid_res_ns struct member to the clock struct, so we have
the clock related stuff in one place.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Geneviève Bastien <gbastien@versatic.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Jeremie Galarneau <jgalar@efficios.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lore.kernel.org/lkml/20200805093444.314999-5-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9d88a1a1
    • J
      perf header: Store clock references for -k/--clockid option · d1e325cf
      由 Jiri Olsa 提交于 
      Add a new CLOCK_DATA feature that stores reference times when
-k/--clockid option is specified.

It contains the clock id and its reference time together with wall clock
time taken at the 'same time', both values are in nanoseconds.

The format of data is as below:

  struct {
       u32 version;  /* version = 1 */
       u32 clockid;
       u64 wall_clock_ns;
       u64 clockid_time_ns;
  };

This clock reference times will be used in following changes to display
wall clock for perf events.

It's available only for recording with clockid specified, because it's
the only case where we can get reference time to wallclock time. It's
can't do that with perf clock yet.

Committer testing:

  $ perf record -h -k

   Usage: perf record [<options>] [<command>]
      or: perf record [<options>] -- <command> [<options>]

      -k, --clockid <clockid>
                            clockid to use for events, see clock_gettime()

  $ perf record -k monotonic sleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.017 MB perf.data (8 samples) ]
  $ perf report --header-only | grep clockid -A1
  # event : name = cycles:u, , id = { 88815, 88816, 88817, 88818, 88819, 88820, 88821, 88822 }, size = 120, { sample_period, sample_freq } = 4000, sample_type = IP|TID|TIME|PERIOD, read_format = ID, disabled = 1, inherit = 1, exclude_kernel = 1, mmap = 1, comm = 1, freq = 1, enable_on_exec = 1, task = 1, precise_ip = 3, sample_id_all = 1, exclude_guest = 1, mmap2 = 1, comm_exec = 1, use_clockid = 1, ksymbol = 1, bpf_event = 1, clockid = 1
  # CPU_TOPOLOGY info available, use -I to display
  --
  # clockid frequency: 1000 MHz
  # cpu pmu capabilities: branches=32, max_precise=3, pmu_name=skylake
  # clockid: monotonic (1)
  # reference time: 2020-08-06 09:40:21.619290 = 1596717621.619290 (TOD) = 21931.077673635 (monotonic)
  $
Original-patch-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Geneviève Bastien <gbastien@versatic.net>
Cc: Ian Rogers <irogers@google.com>
Cc: Jeremie Galarneau <jgalar@efficios.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lore.kernel.org/lkml/20200805093444.314999-4-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d1e325cf
  7. 28 5月, 2020 2 次提交
    • J
      perf session: Try to read pipe data from file · 14d3d540
      由 Jiri Olsa 提交于 
      Ian came with the idea of having support to read the pipe data also from
file. Currently pipe mode files fail like:

  $ perf record -o - sleep 1 > /tmp/perf.pipe.data
  $ perf report -i /tmp/perf.pipe.data
  incompatible file format (rerun with -v to learn more)

This patch adds the support to do that by trying the pipe header first,
and if its successfully detected, switching the perf data to pipe mode.

Committer testing:

  # ls
  # perf record -a -o - sleep 1 > /tmp/perf.pipe.data
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.000 MB - ]
  # ls
  # perf report -i /tmp/perf.pipe.data | head -25
  # To display the perf.data header info, please use --header/--header-only options.
  #
  #
  # Total Lost Samples: 0
  #
  # Samples: 511  of event 'cycles'
  # Event count (approx.): 178447276
  #
  # Overhead  Command   Shared Object      Symbol
  # ........  ........  .................  ...........................................................................................
  #
      65.49%  swapper   [kernel.kallsyms]  [k] native_safe_halt
       6.45%  chromium  libblink_core.so   [.] blink::SelectorChecker::CheckOne
       4.08%  chromium  libblink_core.so   [.] blink::SelectorQuery::ExecuteForTraverseRoot<blink::AllElementsSelectorQueryTrait>
       2.25%  chromium  libblink_core.so   [.] blink::SelectorQuery::FindTraverseRootsAndExecute<blink::AllElementsSelectorQueryTrait>
       2.11%  chromium  libblink_core.so   [.] blink::SelectorChecker::MatchSelector
       1.91%  chromium  libblink_core.so   [.] blink::Node::OwnerShadowHost
       1.31%  chromium  libblink_core.so   [.] blink::Node::parentNode@plt
       1.22%  chromium  libblink_core.so   [.] blink::Node::parentNode
       0.59%  chromium  libblink_core.so   [.] blink::AnyAttributeMatches
       0.58%  chromium  libv8.so           [.] v8::internal::GlobalHandles::Create
       0.58%  chromium  libblink_core.so   [.] blink::NodeTraversal::NextAncestorSibling
       0.55%  chromium  libv8.so           [.] v8::internal::RegExpGlobalCache::RegExpGlobalCache
       0.55%  chromium  libblink_core.so   [.] blink::Node::ContainingShadowRoot
       0.55%  chromium  libblink_core.so   [.] blink::NodeTraversal::NextAncestorSibling@plt
  #
Original-patch-by: NIan Rogers <irogers@google.com>
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Khuong <pvk@pvk.ca>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200507095024.2789147-4-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      14d3d540
    • J
      perf tools: Do not seek in pipe fd during tracing data processing · b491198d
      由 Jiri Olsa 提交于 
      There's no need to set 'fd' position in pipe mode, the file descriptor
is already in proper place. Moreover the lseek will fail on pipe
descriptor and that's why it's been working properly.

I was tempted to remove the lseek calls completely, because it seems
that tracing data event was always synthesized only in pipe mode, so
there's no need for 'file' mode handling. But I guess there was a reason
behind this and there might (however unlikely) be a perf.data that we
could break processing for.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Khuong <pvk@pvk.ca>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200507095024.2789147-3-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b491198d
  9. 06 5月, 2020 2 次提交
  11. 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
  13. 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
  15. 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
  17. 11 12月, 2019 2 次提交
  19. 15 10月, 2019 1 次提交
  21. 26 9月, 2019 1 次提交
  23. 25 9月, 2019 5 次提交
  25. 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
  27. 20 9月, 2019 3 次提交
  29. 01 9月, 2019 1 次提交
  31. 30 8月, 2019 3 次提交
  33. 29 8月, 2019 3 次提交
  35. 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
  37. 30 7月, 2019 6 次提交