lkml.org 
[lkml]   [2011]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH -tip v3 3/6] perf branch trace: print pid and command
    On Fri, Apr 01, 2011 at 11:11:10AM -0600, David Ahern wrote:
    >
    >
    > On 04/01/11 09:13, Frederic Weisbecker wrote:
    > > On Mon, Mar 28, 2011 at 08:31:23AM -0600, David Ahern wrote:
    > >> On 03/28/11 04:34, Akihiro Nagai wrote:
    > >>>> from is sample->ip? to is sample->addr? In the above example
    > >>>> 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which
    > >>>> resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.
    > >>> Yes.
    > >>> In this example, resolved address is only sample->ip (branch from).
    > >>> We need the resolved address of sample->addr (branch to) too, because
    > >>> both of them are addresses of execution code.
    > >>
    > >> Ok, now I understand. In that case add conversion of sample->addr to
    > >> symbols to perf-script.
    > >
    > > I agree that we should rather use perf script for branch dumps.
    > > Sorry Akihiro, I think we suggested you to create this dedicated
    > > perf branch by the past. But then perf script became the vanilla dump
    > > tool in the middle and it seems more suitable today.
    > >
    > > We can still create a perf branch later in order to produce some more
    > > advanced post-processing tools. But for sample dumps perf script (which starts
    > > to show itself as a misnomer BTW) seems to be the right place.
    >
    > perf-dump?

    Yeah. We could make it an alias of perf-script.

    > >
    > > So, in this context, if we have PERF_SAMPLE_ADDR, we are going to always
    > > follow the ip with a "=>" and then resolve the address, etc...
    > >
    > > Yeah it makes sense for this default mode. But what about when we'll want
    > > a function graph kind of output? This will require a totally different
    > > layout. Also PERF_SAMPLE_ADDR may be used for different context in the
    > > future.
    > >
    > > Perhaps we want a kind of per evsel callback that makes its own
    > > interpretation of the pid/tid/dso/sym/etc... options asked by the
    > > user?
    >
    > The print addr function can take the evsel as an input. It includes the
    > event type which can be used to decide what the address means.

    Also yeah. But once we'll have the graph output, that may become
    a real mess.

    >
    > >
    > > But well, we can start simple and make and just do the => trick
    > > if we have PERF_SAMPLE_ADDR and resolve addr if the user asked
    > > the sym. Then when we have the graph output, have these per evsel
    > > display callbacks.
    >
    > There is another email thread about page faults. The user wants sample
    > address resolved to symbols. I was going to look into it next week when
    > I get back from vacation.

    What we seem to need for that is to bring a pagefault tracepoint. We had
    propositions for that in the past, but work on this is in pause mode it
    seems.


    \
     
     \ /
      Last update: 2011-04-06 14:17    [W:0.027 / U:3.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site