Message-ID: <20150518204416.GJ18563@kernel.org>
Date:	Mon, 18 May 2015 17:44:16 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Alexei Starovoitov <ast@...mgrid.com>
Cc:	Wang Nan <wangnan0@...wei.com>, paulus@...ba.org,
	a.p.zijlstra@...llo.nl, mingo@...hat.com, namhyung@...nel.org,
	jolsa@...nel.org, dsahern@...il.com, daniel@...earbox.net,
	brendan.d.gregg@...il.com, masami.hiramatsu.pt@...achi.com,
	lizefan@...wei.com, linux-kernel@...r.kernel.org, pi3orama@....com
Subject: Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to
 load eBPF programs.

Em Mon, May 18, 2015 at 12:38:42PM -0700, Alexei Starovoitov escreveu:
> On 5/17/15 3:56 AM, Wang Nan wrote:
> >This is the 3rd version of 'perf bpf' patch series, based on
> >v4.1-rc3.
> >
> >The goal of this series of patches is to integrate eBPF with perf.
> >After applying these patches, users are allowed to use following
> >command to load eBPF program compiled by LLVM into kernel then start
> >recording with filters on:
> >
> >  # perf bpf record --object sample_bpf.o -- -a sleep 4
> 
> I think using programs are sophisticated filters is a good start
> and are useful already. Let's focus on that at the moment.
> I wouldn't grow the patchset any bigger.

Right, I am just now trying to slowly get involved, and my first
impression would be like that, i.e. we have:

perf record --filter, to pass a filter to tracepoints, if I could
instead of a filter expression pass, say, filter_bpf.o, that would seem
natural for me, i.e. no new option, just an alternative type of filter,
one way more powerful.

If i could write it as a C expression that would then get wrapped up as
a bpf, compiled, turned into an object, and then inserted in the kernel
to be used as my filter, then that would be almost like a tracepoint
filter.
 
> >Other than the previous change, v3 patch series drops the '|' event
> >syntax introduced in v2, because I realized that in v2 users are
> >allowed to pass any bpf fd by using it, like:
> >
> >  # perf bpf record -- -e sched:sched_switch|100| sleep 1

So, what was this supposed to achieve? What does 100 mean there?

> >
> >which may become trouble maker.
> 
> passing fd number as a string is an odd interface anyway.
> So I think that was the right call. We can improve it later.
> 
> >  Are we actually need a 'perf bpf' command? We can get similar result by
> >  modifying 'perf record' to make it load eBPF program before recording.
> >
> >  I suggest to keep 'perf bpf', group all eBPF stuffs together using a
> >  uniform entry. Also, eBPF programs can act not only as filters but also
> >  data aggregator. It is possible to make something link 'perf bpf run'
> >  to simply make it run, and dump result after user hit 'C-c' or timeout.
> 
> Though it's tempting to group under 'perf bpf'. I think it's cleaner to
> add --object flag to 'perf record'

I'd say keep it in --filter, that noticing it is a bpf object would
dtrt:

  perf record --filter bpf_thing.o usleep 1


> Since it will avoid unnecessary '--'.
> Unless we can drop it? Like
> perf bpf record --object sample_bpf.o -a sleep 4
> should work?
> If not, then the following is better:
> perf record --object sample_bpf.o -a sleep 4
> 
> Thank you for the hard work!

Ditto!

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists