All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>, Jiri Olsa <jolsa@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@linux.intel.com>, Ian Rogers <irogers@google.com>
Subject: [PATCH 0/4] Handle chroot tasks properly (v2)
Date: Tue,  1 Feb 2022 23:08:24 -0800	[thread overview]
Message-ID: <20220202070828.143303-1-namhyung@kernel.org> (raw)

Hello,

I found that perf tools don't work well with tasks in a chroot.  The
filenames in MMAP record are from the root directory of the task so
it's different than what it sees from outside.

 * changes in v2)
  - add Jiri's Acked-by
  - split stderr setup for objdump

I've tested it with a simple program (myprog - statically built) which
just consumes cpu cycles in a loop for a while (default 1 sec, can by
overridden by a command-line argument).

  # cd $HOME
  # mkdir -p myroot/bin
  # cp myprog myroot/bin

  # perf record chroot myroot myprog
  # perf report -D | grep MMAP | grep myprog
  2084916774977911 0xa2e4 [0x70]: PERF_RECORD_MMAP2 3363818/3363818: \
  [0x401000(0x80000) @ 0x1000 fe:01 4346398 2543719070]: r-xp /bin/myprog

So it's reported as /bin/myprog and then it's unable to symbolize the
samples.  It seems hard to fix it for the above use case as the record
ended after the task exited.  It cannot know the root directory of the
task anymore.  But we can fix it for real-time use cases like perf top
or pipe-mode at least.

I tested it again with the following command.

  # perf record -o- chroot myroot myprog | perf report -i-
  ...
  #
  # Overhead  Command  Shared Object      Symbol                          
  # ........  .......  .................  ................................
  #
      46.02%  myprog   myprog             [.] 0x000000000000178a
      36.71%  myprog   myprog             [.] 0x0000000000001792
      17.12%  myprog   myprog             [.] 0x000000000000178e
       0.05%  myprog   myprog             [.] 0x0000000000001796
       0.05%  chroot   ld-2.33.so         [.] intel_check_word.constprop.0

The symbols are not resolved because it failed to load the symbol
table as it didn't find the file in the given path.

So I modified the code to try a new name prepended with the task's
root directory when it's not "/".  With this change, I can see the
symbols of myprog.  In fact, it depends on timing if perf report hits
the file before the task is gone.  Increasing the loop time to 3 sec
helped it to get symbols reliably.

  # perf record -o- chroot myroot myprog 3 | perf report -i-
  ...
  #
  # Overhead  Command  Shared Object      Symbol                       
  # ........  .......  .................  .............................
  #
      99.83%  myprog   myprog             [.] loop
       0.04%  chroot   [kernel.kallsyms]  [k] fxregs_fixup
       0.04%  chroot   [kernel.kallsyms]  [k] rsm_load_seg_32
       0.03%  chroot   [kernel.kallsyms]  [k] show_cpuinfo_cur_freq
       0.01%  myprog   [kernel.kallsyms]  [k] alarmtimer_fired


I also found that perf inject and perf annotate need the similar changes.

You can get it from 'perf/dso-chroot-v2' branch at

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git


Thanks,
Namhyung


Namhyung Kim (4):
  perf annotate: Set error stream of objdump process for TUI
  perf tools: Try chroot'ed filename when opening dso/symbol
  perf inject: Try chroot directory when reading build-id
  perf annotate: Try chroot filename for objdump

 tools/perf/builtin-inject.c | 10 ++++++++++
 tools/perf/util/annotate.c  | 11 +++++++++++
 tools/perf/util/dso.c       | 15 +++++++++++++--
 tools/perf/util/dsos.c      | 13 +++++++++++++
 tools/perf/util/symbol.c    | 10 ++++++++++
 tools/perf/util/util.c      | 31 +++++++++++++++++++++++++++++++
 tools/perf/util/util.h      |  2 ++
 7 files changed, 90 insertions(+), 2 deletions(-)


base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07
-- 
2.35.0.rc2.247.g8bbb082509-goog


             reply	other threads:[~2022-02-02  7:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02  7:08 Namhyung Kim [this message]
2022-02-02  7:08 ` [PATCH 1/4] perf annotate: Set error stream of objdump process for TUI Namhyung Kim
2022-02-02  7:08 ` [PATCH 2/4] perf tools: Try chroot'ed filename when opening dso/symbol Namhyung Kim
2022-02-02  7:08 ` [PATCH 3/4] perf inject: Try chroot directory when reading build-id Namhyung Kim
2022-02-02  7:08 ` [PATCH 4/4] perf annotate: Try chroot filename for objdump Namhyung Kim
2022-02-10 18:34 ` [PATCH 0/4] Handle chroot tasks properly (v2) Arnaldo Carvalho de Melo
2022-02-11  6:16   ` Namhyung Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220202070828.143303-1-namhyung@kernel.org \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.