Message-ID: <20150519134458.GC13946@kernel.org>
Date:	Tue, 19 May 2015 10:44:58 -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 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.

> 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, I would like it too.

- 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