Messages in this thread | | | Date | Tue, 26 May 2015 14:22:51 +0800 | From | "Wangnan (F)" <> | Subject | Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs. |
| |
On 2015/5/20 4:46, Alexei Starovoitov wrote: > On 5/19/15 9:40 AM, Arnaldo Carvalho de Melo wrote: >> Em Wed, May 20, 2015 at 01:04:48AM +0900, Namhyung Kim escreveu: >>> On Tue, May 19, 2015 at 10:44:58AM -0300, Arnaldo Carvalho de Melo >>> wrote: >>>> Em Mon, May 18, 2015 at 02:45:58PM -0700, Alexei Starovoitov escreveu: >>>>> On 5/18/15 2:20 PM, Arnaldo Carvalho de Melo wrote: >>>>>> perf record --event bpf_thing.o >>>> >>>>>> Looks more natural then, as it is an event that will take place >>>>>> when the >>>>>> filter returns true, and in addition to that, it will come with a >>>>>> bunch >>>>>> of variables, etc. >>>>> >>>>> well, I think --event fits a bit less than --filter ;) >>>>> Both not ideal. >>>> >>>> I thought --event was more suited, as it states what is the event, and >>>> when it should happen, i.e. --filter is about reducing the >>>> frequency of >>>> something well defined, i.e. an existing --event. >>> >>> If we go with 'perf record' rather than 'perf bpf record', I agree >>> that --event option is more natural than --filter. The --event option >>> says that it will record - or enable, at least - a (kprobe) event for >>> bpf programs in it and then do something with it. :) >>> >>> Maybe something like this? >>> >>> perf record --event bpf:/path/to/object >> >> The syntax maybe one of many, say if it sees a ".o" suffix in the even >> name, look if the provided event name is a file and if this file has the >> ELF header, whatever. > > agree. 'bpf:' prefix is redundant. > To me the following syntax is fine: > perf record --event bpf_file.o > > In the future it can support automatically: > perf record --event bpf_file.c > > Wang, thoughts? >
After reading the full thread I think we finally agree that the user interface should be
perf record --event bpf_file.o
for event filtering case. I'll do this in next version.
Thank you.
>>> Oh, this looks like an interesting approach.. are you saying something >>> like below? >> >> No, those are way too many steps :-) >> >> What 'perf script' does? Right now you can ask for a script to run and >> it will both start 'perf record' with the proper events, and then >> "immediately" consume it, piping the output of the 'record' "script" to >> the consumer, that is 'perf script' itself running an interpreter, perl >> or python. > > if you're proposing to do something like: > perf script bpf_file.c > that will do event creation, filtering, aggregation, reporting > and printing results, then it's fine. > This is pretty much what I thought 'perf bpf run' will do. > >> I.e. the first part, say, failed-syscalls-record, would be done >> internally, loading the bpf object, etc, the second part would be the >> event massaging, but done in a C subset :-) > > not sure that's doable. The task (perf) that loaded the program in the > step one should be still alive when 2nd part is running. > For 'perf bpf run' use case, the whole record/report split is > artificial. There is no need for perf.data. > In my mind 'perf bpf run file.c' suppose to quickly compile .c, > hook into kernel, collect and print something, then Ctrl-C of > 'perf bpf run' should automatically stop everything. > No perf.data anywhere. It should be quick single step > tool for live debugging. > At the same time 'perf record --event bpf_file.o' plus generic > 'perf report' model works very well as well. > They are different use cases. > > I guess I'm saying let's not get too much ahead of ourselves ;) > I think Wang's current patchset is close enough to make > 'perf record --event bpf_file.o' to be useful. > Let's take this first step. >
| |