Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751801AbbETAdR (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 May 2015 20:33:17 -0400
Received: from lgeamrelo01.lge.com ([156.147.1.125]:35010 "EHLO
	lgeamrelo01.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750879AbbETAdP (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 May 2015 20:33:15 -0400
X-Original-SENDERIP: 10.177.220.203
X-Original-MAILFROM: namhyung@kernel.org
Date: Wed, 20 May 2015 09:23:50 +0900
From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@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: <20150520002350.GD22713@sejong>
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>
 <20150519164040.GB19921@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150519164040.GB19921@kernel.org>
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: 4693
Lines: 108

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/