lkml.org 
[lkml]   [2017]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 tip/perf/core 1/6] perf symbols: find symbols in different mount namespace
    Em Mon, Jul 10, 2017 at 03:39:25PM -0700, Krister Johansen escreveu:
    > On Mon, Jul 10, 2017 at 08:17:00AM +0200, Thomas-Mich Richter wrote:
    > > On 07/07/2017 09:36 PM, Krister Johansen wrote:
    > > > On Thu, Jul 06, 2017 at 04:41:30PM -0300, Arnaldo Carvalho de Melo wrote:
    > > >> Em Wed, Jul 05, 2017 at 06:48:08PM -0700, Krister Johansen escreveu:
    > > >>> Teach perf how to resolve symbols from binaries that are in a different
    > > >>> mount namespace from the tool. This allows perf to generate meaningful
    > > >>> stack traces even if the binary resides in a different mount namespace
    > > >>> from the tool.
    > > >>
    > > >> I was trying to find a way to test after applying each of the patches in
    > > >> this series, when it ocurred to me that if a process that appears on a
    > > >> perf.data file has exit, how can we access /proc/%ITS_PID/something?
    > > >
    > > > You're correct. We can't access /proc/<PID>/whatever once the process
    > > > has exited. That was the impeteus for patches 4 and 6, which allow us
    > > > to capture the binary (and debuginfo, if it exists) into the buildid
    > > > cache so that if we do have a trace that exists after a process or
    > > > container exists, we'll still be able to resolve some of the symbols.

    > > Any ideas on how to extend this to be able to resolve symbols after
    > > the process/container exited?
    > > I believe it boils down on how to interpret the mnt inode number in the
    > > PERF_RECORD_NAMESPACE record...
    > > Can this be done post-mortem? Maybe the PERF_RECORD_NAMESPACE record
    > > has to contain more data than just the inode number?

    > I think we're talking past one another. If the container exits then the
    > inode numbers that identify mount namespace are referring to something
    > that is no longer valid. There's no mount namespace to enter in order
    > to locate the binary objects. They may be on a volume that's no longer
    > mounted.

    > I have a pair of patches in the existing set that copies the binary
    > objects into the buildid cache. This lets you resolve the symbols after
    > the container has exited, provided that you recorded the buildids during
    > the trace.

    > If you apply all the patches in this set, you should be able to generate
    > traces that you can look at with script or report even after the process
    > has exited. I've been able to do it in my tests, at least.

    I will work on testing them soon, I just wanted this discussion to take
    place, what you did seems to be the best we can do with the existing
    kernel infrastructure, and is a clear advance, so we need to test and
    merge it.

    Getting the build-ids for the binaries is the key here, then its just a
    matter of populating a database where to get the matching binaries, we
    wouldn't need even to copy the actual binaries at record time.

    - Arnaldo

    \
     
     \ /
      Last update: 2017-07-11 00:54    [W:4.288 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site