lkml.org 
[lkml]   [2012]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] perf: Add a new sort order: SORT_INCLUSIVE (v4)
    On 3/15/12 7:14 AM, Frederic Weisbecker wrote:

    > I still feel concerned about this.
    >
    > If I have only one event with a period of 1 and with that callchain:
    >
    > a -> b -> c
    >
    > Then I produce three hists
    >
    > 1) a -> b -> c
    > 2) a -> b
    > 3) a
    >
    > Each hist have a period of 1, but the total period is 1.
    > So the end result should be (IIUC):
    >
    > 100% foo a
    > 100% foo b
    > |
    > --- a
    > 100% foo c
    > |
    > --- b
    > |
    > --- c
    >

    That is correct. The first column no longer adds up to 100%.

    > And the percentages on callchain branches will have the same kind
    > of weird things.

    I expect --sort inclusive to be used with -g graph,0.5,caller. I can
    polish this in the next rev where a single top level flag will set this up.

    The percentages on the branches should still be accurate (as a
    percentage of total_period). Please let me know if this is not the case.

    >
    > So I'm not sure this is a good direction. I'd rather advocate to create
    > true hists for each callers, all having the same real period as the leaf.
    >

    Please see the v5 I just posted. The callers have a true histogram entry
    in every sense, except that period_self == 0.

    If we don't do this, total_period will be inflated.

    > Also this feature reminds me a lot the -b option in perf report.
    > Branch sorting and callchain inclusive sorting are a bit different in
    > the way they handle the things but the core idea is the same. Callchains
    > are branches as well.
    >

    Yes - I kept asking why the branch stack stuff doesn't use the existing
    callchain logic.

    > Branch sorting (-b) adds a hist for every branch taken, and the period
    > is always 1. I wonder if this makes more sense than using the original
    > period of the event for all branches of the event. Not sure.
    >
    > Anyway I wonder if both features can be better integrated. After all
    > they are about the same thing. The difference is that the source of
    > the branches is not the same and that callchains can be depicted into
    > trees.
    >
    > So perhaps we can have -b specifying the desired source, in case both
    > are present: -b callchain and -b branch. Both at the same time wouldn't
    > make much sense I think.
    >
    > And the source could default to either if we don't have callchain and
    > branch at the same time in the events.
    >
    > Just an idea...

    I haven't played much with the branch stack logic. Will do so and get back.

    In the meanwhile, my impression is that there are two high level use cases:

    * Compiler optimizers, tracing JITs etc

    Which try to focus on a single branch and try to understand what
    happened with that branch

    * Programmers who're trying to understand the behavior of the code they
    wrote in production

    I think the branch-stack stuff primarily caters to the former and
    inclusive callchain stuff to the latter. I was thinking that getting the
    branch-stack data into callchains will make the data more useful to more
    people.

    -Arun


    \
     
     \ /
      Last update: 2012-03-15 19:01    [W:0.030 / U:0.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site