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

[Namhyung Kim]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/