Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs.

[Namhyung Kim <namhyung@kernel.org>]

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>