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

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, May 19, 2015 at 06:02:13PM -0700, Alexei Starovoitov escreveu:
> On 5/19/15 3:05 PM, Arnaldo Carvalho de Melo wrote:
> >
> >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.

Thanks! I'll continue tomorrow, reading those examples as well messages
I saw on netdev.

- Arnaldo
 
> There are different use cases that would fit in different perf commands.
> - 1st use case is quick kernel debugging which could be something
> similar to: samples/bpf/tracex1_kern.c
> where the user would type a little program with some filtering and
> printing and will say 'perf script prog.c'
> where it would compile (in microseconds), load, hook into kernel
> and print stuff to the screen.
> If it prints too much, the user will just Ctrl-C, tweak the prog
> and repeat.
> I'm seeing it as replacement of 'add printk to kernel, recompile,
> reboot' cycle.
> 
> - 2nd use case is performance analysis of various things where
> aggregation is happening in the kernel and data is printed by
> user space in human friendly way. There are three main categories
> of visualization: histograms, heatmaps, flamegraphs.
> The program will collect the data into such structures
> and perf will be visualizing them.
> Currently tracex2 is an example of histogram, tracex3 - heatmap
> and flamegraphs in the works.
> 
> - 3rd use case is 'top' like visualization
>   tracex4 example is trying to demo it.
> 
> these are my use cases.
> - Wang's use case turned out to be 4th category.
> My understanding he wants to write a program that pretty
> much sophisticated filter with dependencies across multiple
> events in the system and at the end visualize one 'master'
> event via 'perf report'.
> That's what this patch set is about.
> I think 'perf record --event file.o' + 'perf report' fits
> Wang's use case quite well.
> My 1st use case fits 'perf script file.c' model.
> How to fit 2 and 3 into perf is hard to see yet.