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 > > > May be --bpfobj would be a better flag, since it's a clean slate. > > Short version '-b' is also unused :) > > Anything with "bpf" seems artificial ;-\ Using short options for > something controvertial also doesn't seems like a good idea :-) > > >> And if that is the case, then what is the difference from a kprobe > >> event? I.e. for the existing tooling it wouldn't matter how this event > >> was set up, as long as it was available via tracefs, etc. I.e. it would > >> be completely similar to a tracepoint, kprobe, uprobe, etc, i.e. first > >> set it up, expose its internals via tracefs, no changes to perf. > > > the main difference that programs are not static as kprobes. > > Well, I could, and indeed have been thinking about, using kprobes as > part of the 'trace' process, i.e. to collect things not available in > existing data sources (aka --event's), for the purposes of a tracing > session, i.e. it would be set up and torn down as part of calling > 'perf trace foo-workload'. > > In this sense it would be more "not static", with the only caveat that > with the current way of setting up (ku)probes, it would be available for > whoever would wanted to/could use it while that tracing session would be > underway. > > > bpf maps, programs need to be dynamically created and loaded and they > > will cease to exist as soon as process that holds FDs exits. So it > > Ok, so its just that the setting up of the event is hardwired with the > use of it via --event in the command line. > > Or, looking at it another way, using it via --event would set it up > _and_ use it, then tear it down. > > > matches perf_event_open model which is FD based as well. > > And that's only filtering like usage. Where 'perf report' facilities > > are reused. For 'kernel debugging', 'latency heatmaps' use cases some > > new visualizations in perf will be needed. That's where > > 'perf bpf command' fits. > > Humm, why not use 'perf script', 'perf trace' as well for those things? > > A 'perf script' that actually uses a C subset, gets compiled by llvm and > then immediately used, with caching for amortizing llvm calls if those > are that expensive, etc, instead of the current python or perl scripting > would come in handy for people like PeterZ, right? Oh, this looks like an interesting approach.. are you saying something like below? 1. bpf generation # add kprobe event to be used by bpf program $ perf probe --add <wanted function> # record dummy data file for the event above $ perf record -e <probe> # generate sample bpf program for the event $ perf script --gen-script bpf # write the program and compile it with llvm # copy the resulting binary into $PERF_EXEC_PATH # now 'perf script --list' should show the bpf object/script # delete kprobe event $ perf probe --del <probe> 2. usage # do the real work here via shell script # add kprobe event, load and attach bpf program, delete kprobe after record $ perf script record <bpf script> # maybe we can have custom code/script to display the result $ perf script report <bpf script> -- 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/
