Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755989AbbESQkr (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 May 2015 12:40:47 -0400
Received: from mail.kernel.org ([198.145.29.136]:52740 "EHLO mail.kernel.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752084AbbESQkp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 May 2015 12:40:45 -0400
Date: Tue, 19 May 2015 13:40:40 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>, Wang Nan <wangnan0@huawei.com>,
        paulus@samba.org, a.p.zijlstra@chello.nl, mingo@redhat.com,
        jolsa@kernel.org, dsahern@gmail.com, daniel@iogearbox.net,
        brendan.d.gregg@gmail.com, masami.hiramatsu.pt@hitachi.com,
        lizefan@huawei.com, linux-kernel@vger.kernel.org, pi3orama@163.com
Subject: Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to
 load eBPF programs.
Message-ID: <20150519164040.GB19921@kernel.org>
References: <1431860222-61636-1-git-send-email-wangnan0@huawei.com>
 <555A3FC2.8060805@plumgrid.com>
 <20150518204416.GJ18563@kernel.org>
 <555A541F.6090606@plumgrid.com>
 <20150518212013.GB13946@kernel.org>
 <555A5D96.2070509@plumgrid.com>
 <20150519134458.GC13946@kernel.org>
 <20150519160448.GD29162@danjae.kornet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150519160448.GD29162@danjae.kornet>
X-Url: http://acmel.wordpress.com
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3933
Lines: 88

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

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 :-)

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