Messages in this thread | | | Date | Mon, 18 May 2015 17:44:16 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs. |
| |
Em Mon, May 18, 2015 at 12:38:42PM -0700, Alexei Starovoitov escreveu: > On 5/17/15 3:56 AM, Wang Nan wrote: > >This is the 3rd version of 'perf bpf' patch series, based on > >v4.1-rc3. > > > >The goal of this series of patches is to integrate eBPF with perf. > >After applying these patches, users are allowed to use following > >command to load eBPF program compiled by LLVM into kernel then start > >recording with filters on: > > > > # perf bpf record --object sample_bpf.o -- -a sleep 4 > > I think using programs are sophisticated filters is a good start > and are useful already. Let's focus on that at the moment. > I wouldn't grow the patchset any bigger.
Right, I am just now trying to slowly get involved, and my first impression would be like that, i.e. we have:
perf record --filter, to pass a filter to tracepoints, if I could instead of a filter expression pass, say, filter_bpf.o, that would seem natural for me, i.e. no new option, just an alternative type of filter, one way more powerful.
If i could write it as a C expression that would then get wrapped up as a bpf, compiled, turned into an object, and then inserted in the kernel to be used as my filter, then that would be almost like a tracepoint filter.
> >Other than the previous change, v3 patch series drops the '|' event > >syntax introduced in v2, because I realized that in v2 users are > >allowed to pass any bpf fd by using it, like: > > > > # perf bpf record -- -e sched:sched_switch|100| sleep 1
So, what was this supposed to achieve? What does 100 mean there?
> > > >which may become trouble maker. > > passing fd number as a string is an odd interface anyway. > So I think that was the right call. We can improve it later. > > > Are we actually need a 'perf bpf' command? We can get similar result by > > modifying 'perf record' to make it load eBPF program before recording. > > > > I suggest to keep 'perf bpf', group all eBPF stuffs together using a > > uniform entry. Also, eBPF programs can act not only as filters but also > > data aggregator. It is possible to make something link 'perf bpf run' > > to simply make it run, and dump result after user hit 'C-c' or timeout. > > Though it's tempting to group under 'perf bpf'. I think it's cleaner to > add --object flag to 'perf record'
I'd say keep it in --filter, that noticing it is a bpf object would dtrt:
perf record --filter bpf_thing.o usleep 1
> Since it will avoid unnecessary '--'. > Unless we can drop it? Like > perf bpf record --object sample_bpf.o -a sleep 4 > should work? > If not, then the following is better: > perf record --object sample_bpf.o -a sleep 4 > > Thank you for the hard work!
Ditto!
- Arnaldo
| |