Messages in this thread | | | Date | Tue, 19 May 2015 19:05:29 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs. |
| |
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
| |