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

Namhyung Kim
2015-05-20T00:33:17Z

On Tue, May 19, 2015 at 01:40:40PM -0300, 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.

I was thinking about something similar for SDT. I think that it'll
eventually handle ELF files as an event somehow, no? Maybe we need to
add ".bpf" suffix?

>
> <SNIP>
>
> > > > 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?
>
> 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.

Ah, okay. So 'perf script <xxx>' is same as 'perf script record <xxx> -o- | \
perf script report <xxx> -i-', right?

>
> Look at:
>
> [acme@ssdandy linux]$ ls -la ~/libexec/perf-core/scripts/perl/bin/
> total 64
> drwxr-xr-x. 2 acme acme 4096 May 19 11:53 .
> drwxr-xr-x. 4 acme acme 4096 May 19 11:53 ..
> -rwxr-xr-x. 1 acme acme 78 May 19 11:53 check-perf-trace-record
> -rwxr-xr-x. 1 acme acme 132 Jan 6 11:36 check-perf-trace-report
> -rwxr-xr-x. 1 acme acme 109 May 19 11:53 failed-syscalls-record
> -rwxr-xr-x. 1 acme acme 241 May 19 11:53 failed-syscalls-report
> -rwxr-xr-x. 1 acme acme 83 May 19 11:53 rw-by-file-record
> -rwxr-xr-x. 1 acme acme 232 May 19 11:53 rw-by-file-report
> -rwxr-xr-x. 1 acme acme 135 May 19 11:53 rw-by-pid-record
> -rwxr-xr-x. 1 acme acme 114 May 19 11:53 rw-by-pid-report
> -rwxr-xr-x. 1 acme acme 135 May 19 11:53 rwtop-record
> -rwxr-xr-x. 1 acme acme 398 May 19 11:53 rwtop-report
> -rwxr-xr-x. 1 acme acme 75 May 19 11:53 wakeup-latency-record
> -rwxr-xr-x. 1 acme acme 133 May 19 11:53 wakeup-latency-report
> -rwxr-xr-x. 1 acme acme 160 Jan 6 13:05 workqueue-stats-record
> -rwxr-xr-x. 1 acme acme 136 Jan 6 13:05 workqueue-stats-report
> [acme@ssdandy linux]$
>
> 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 :-)

IIRC there's a patch posted to support C for scripting.

https://lkml.org/lkml/2014/5/22/13

Are you saying about it? A rough idea is that it'd be nice to have a
kind of this report/display code in a section of the bpf file itself.

Thanks,
Namhyung