Messages in this thread | | | Date | Thu, 15 Mar 2012 10:58:38 -0700 | From | Arun Sharma <> | Subject | Re: [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
| |