linux.git/tools/perf/util/header.c, branch v5.10

perf tools: Add size to 'struct perf_record_header_build_id'

2020-10-14T14:28:12+00:00

We do not store size with build ids in perf data, but there's enough
space to do it. Adding misc bit PERF_RECORD_MISC_BUILD_ID_SIZE to mark
build id event with size.

With this fix the dso with md5 build id will have correct build id data
and will be usable for debuginfod processing if needed (coming in
following patches).

Committer notes:

Use %zu with size_t to fix this error on 32-bit arches:

  util/header.c: In function '__event_process_build_id':
  util/header.c:2105:3: error: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' [-Werror=format=]
     pr_debug("build id event received for %s: %s [%lu]\n",
     ^

Signed-off-by: Jiri Olsa 
Acked-by: Ian Rogers 
Link: https://lore.kernel.org/r/20201013192441.1299447-8-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Pass build_id object to dso__set_build_id()

2020-10-14T11:46:42+00:00

Passing build_id object to dso__set_build_id(), so it's easier
to initialize dos's build id object.

Signed-off-by: Jiri Olsa 
Acked-by: Ian Rogers 
Link: https://lore.kernel.org/r/20201013192441.1299447-6-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Pass build_id object to build_id__sprintf()

2020-10-14T11:46:22+00:00

Passing build_id object to build_id__sprintf function, so it can operate
with the proper size of build id.

This will create proper md5 build id readable names,
like following:

  a50e350e97c43b4708d09bcd85ebfff7

instead of:

  a50e350e97c43b4708d09bcd85ebfff700000000

Signed-off-by: Jiri Olsa 
Acked-by: Ian Rogers 
Link: https://lore.kernel.org/r/20201013192441.1299447-5-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Use build_id object in dso

2020-10-14T11:44:47+00:00

Replace build_id byte array with struct build_id object and all the code
that references it.

The objective is to carry size together with build id array, so it's
better to keep both together.

This is preparatory change for following patches, and there's no
functional change.

Signed-off-by: Jiri Olsa 
Acked-by: Ian Rogers 
Link: https://lore.kernel.org/r/20201013192441.1299447-2-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix module symbol processing

2020-08-13T12:57:40+00:00

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
  
  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: 02213cec64bb ("perf maps: Mark module DSOs with kernel type")
Reported-by: Arnaldo Carvalho de Melo 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Adrian Hunter 
Cc: Namhyung Kim 
Signed-off-by: Jiri Olsa

perf tools: Rename 'enum dso_kernel_type' to 'enum dso_space_type'

2020-08-13T12:53:21+00:00

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: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Move clockid_res_ns under clock struct

2020-08-06T12:42:20+00:00

Move the clockid_res_ns struct member to the clock struct, so we have
the clock related stuff in one place.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Geneviève Bastien 
Cc: Ian Rogers 
Cc: Jeremie Galarneau 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: http://lore.kernel.org/lkml/20200805093444.314999-5-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf header: Store clock references for -k/--clockid option

2020-08-06T12:35:06+00:00

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 [] []
      or: perf record [] --  []

      -k, --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: David Ahern 
Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Geneviève Bastien 
Cc: Ian Rogers 
Cc: Jeremie Galarneau 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: http://lore.kernel.org/lkml/20200805093444.314999-4-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf session: Try to read pipe data from file

2020-05-28T13:03:25+00:00

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
       2.25%  chromium  libblink_core.so   [.] blink::SelectorQuery::FindTraverseRootsAndExecute
       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: Ian Rogers 
Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Paul Khuong 
Cc: Peter Zijlstra 
Link: http://lore.kernel.org/lkml/20200507095024.2789147-4-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Do not seek in pipe fd during tracing data processing

2020-05-28T13:03:25+00:00

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: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Paul Khuong 
Cc: Peter Zijlstra 
Link: http://lore.kernel.org/lkml/20200507095024.2789147-3-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo