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%. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
