From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: "linux-perf-use." <linux-perf-users@vger.kernel.org>
Subject: Re: perf and containers
Date: Thu, 29 Jun 2017 23:16:54 -0300 [thread overview]
Message-ID: <20170630021654.GE12064@kernel.org> (raw)
In-Reply-To: <CAE40pdcP42zaBP_nZa1rdG7D6gDA-X2+Y6FbMfkzfkgFTnz3qA@mail.gmail.com>
Em Thu, Jun 29, 2017 at 01:33:37PM -0700, Brendan Gregg escreveu:
> G'Day perf-users,
>
> I've been using perf with containers a lot, running perf from the host
> system-wide or with --cgroup for one container, and I'm wondering
> about symbol translation and namespaces. When running "perf script" or
> "perf report" from the host:
>
> - kernel symbols: works fine
>
> - JIT symbols: doesn't work as /tmp/perf-PID.map is in the container,
> not the host, and has a different PID. I currently have shell scripts
> to copy and rename map files, but... Would it be possible for perf to
> try opening /tmp/perf-PID.map, and if that fails, check if the PID
> still exists in /proc, read its NSpid from /proc/PID/status, and if
> that's different (meaning it's in a container), then read
> /proc/PID/root/tmp/perf-NSpid.map instead?
>
> - binary symbols: /usr/bin/node,
> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, /lib/..., etc, may not
> be in the host, so symbol translation fails. Could perf have a similar
> approach where it tries from /proc/PID/root/... instead, if the PID is
> in a container?
Yeah, I watched your presentation :-)
We need to fix it properly, using the workarounds you describe as a
starting point, patches trying to attack this piecemeal would be more
than welcome, else I'll try to work on this at some point.
- Arnaldo
> Or, are there other workarounds I don't know about for these? :) perf
> could have a --setns flag to set the mount namespace before it
> attempts symbol translation, which may also work for when I'm
> analyzing one container only from the host, and could run "perf script
> --setns=..." for that one container.
>
> Using perf from within the container is totally different, and not
> always possible (perf_event_open() can be disabled, and, some
> containers are completely locked down, such that it's hard to run any
> command that isn't the application)...
>
> Brendan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-06-30 2:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 20:33 perf and containers Brendan Gregg
2017-06-30 2:16 ` Arnaldo Carvalho de Melo [this message]
2017-06-30 7:00 ` Thomas-Mich Richter
2017-06-30 14:55 ` David Ahern
2017-06-30 17:13 ` Milian Wolff
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=20170630021654.GE12064@kernel.org \
--to=acme@kernel.org \
--cc=brendan.d.gregg@gmail.com \
--cc=linux-perf-users@vger.kernel.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.