Messages in this thread | | | Date | Tue, 29 Oct 2013 09:36:59 +0100 | From | Frederic Weisbecker <> | Subject | Re: State of "perf: Add a new sort order: SORT_INCLUSIVE" |
| |
On Mon, Oct 28, 2013 at 09:10:38PM -0700, Arun Sharma wrote: > On 10/28/13 8:11 PM, Namhyung Kim wrote: > > Hey Namhyung: > > >> > >>Also, what's the reasoning for --cumulate not being an option under > >>perf record -g ..,<order>? > > > >Sorry, I cannot understand you. The 'perf record' just saves sample > >data (and callchains) from the ring-buffer. All the processing happens > >in 'perf report'. I can't see what you expect from the 'perf record > >--cumulate'. Am I missing something? > > Yes - I meant to say perf report -g :) > > > -g [type,min[,limit],order] > > Specifically, along with callee, caller, we could have a third > option. Or we could have a new type (graph, fractal, cumulative). > > >>Given that there are clear use cases in production involving complex > >>callgraphs, I'm for getting this support in first and then reconciling > >>the differences with perf record -b later. > > > >I think what Frederic said is that the code de-duplication of 'perf > >report' side. The branch stack and --cumulate are different - branch > >stack concentrates on the branch itself but --cumulate uses callchains > >to find parents and give some credit to them as side information. > > Me too. I brought it up with Stephane at some point in the last year > or so and there wasn't an obvious way to de-duplicate because of > these differences.
I agree that the interface is debatable. It could be -g ...,cumulative, expand -b, or whatever. But the backend is the same: perf_report__add_branch_hist_entry should be shared 80%.
| |