Em Tue, May 19, 2015 at 02:42:11PM -0700, Alexei Starovoitov escreveu: > On 5/19/15 2:10 PM, Arnaldo Carvalho de Melo wrote: > > > >This all should use infrastructure in perf for symbol resolving, > >callcahins, etc. > > yes. 100% > > >Right, but if we do a: > > > >perf script -i perf.data bpf_file.c > > > >Then there would be a short circuit effect of just doing the > >aggregation and/or reporting.
Ok, can you point me to this bpf_file.c, an example? So that we can talk about the parts of it that would be short circuited when not loading the bpf_file.o, etc. > That can work, but I don't see why I would use bpf for > scripting on top of perf.data. If trace is already collected, > the existing perl/python scripts will work fine. > >Well, we could have a tee like mode where perf.data file could be > >generated so that we could run it again after doing some change on the > >aggregation code, so that we wouldn't have to re-run the data collection > >parts, that could be about some condition hard to capture, etc. > > true, but again I don't think in such scenario you'd need bpf. > bpf is needed when the number of events is huge and the user > needs to aggregate/process them in-kernel. > > >>I guess I'm saying let's not get too much ahead of ourselves ;) > > > >No problem, but then we need to talk at this moment not to add new stuff > >that we think should not be added, like 'perf bpf' :-) > > ahh, that's where you going :) Sure. I don't mind avoiding that :-) If there is no need, why add a new command? I.e. if all that is wanted can be used by integrating eBPF into existing commands, that could be best. > unbearable abbreviation if we can :) :-) > 'perf script file.[oc]' command line works for me. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
