Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752458AbbETAhu (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 May 2015 20:37:50 -0400
Received: from mail.kernel.org ([198.145.29.136]:50313 "EHLO mail.kernel.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752101AbbETAhq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 May 2015 20:37:46 -0400
Date: Tue, 19 May 2015 21:37:41 -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: <20150520003741.GE26111@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>
 <20150519164040.GB19921@kernel.org>
 <20150520002350.GD22713@sejong>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150520002350.GD22713@sejong>
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: 4750
Lines: 103

Em Wed, May 20, 2015 at 09:23:50AM +0900, Namhyung Kim escreveu:
> 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:
> > > 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?

Well, if both are ELF files, then probably they will have something that
is unique to them, like perhaps some init function, or some section name
that can be used to disambiguate, no?
 
> > <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?

Something like that, but without two commands spawned using pipes for
communication.
 
> > 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

Lemme look at it... Yeah, that is part of what needs to be done, i.e.
somehow we need to get the .c "script", build it and connect it to the
perf tool.
 
> 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.

Exactly. All in one file, parts of it built for specific purposes and
loaded in each needed way, then all gets connected.

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