Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756223AbbESQGR (ORCPT ); Tue, 19 May 2015 12:06:17 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:36182 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207AbbESQGM (ORCPT ); Tue, 19 May 2015 12:06:12 -0400 Date: Wed, 20 May 2015 01:04:48 +0900 From: Namhyung Kim To: Arnaldo Carvalho de Melo Cc: Alexei Starovoitov , Wang Nan , 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: <20150519160448.GD29162@danjae.kornet> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150519134458.GC13946@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4398 Lines: 109 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 > > > 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, this looks like an interesting approach.. are you saying something like below? 1. bpf generation # add kprobe event to be used by bpf program $ perf probe --add # record dummy data file for the event above $ perf record -e # generate sample bpf program for the event $ perf script --gen-script bpf # write the program and compile it with llvm # copy the resulting binary into $PERF_EXEC_PATH # now 'perf script --list' should show the bpf object/script # delete kprobe event $ perf probe --del 2. usage # do the real work here via shell script # add kprobe event, load and attach bpf program, delete kprobe after record $ perf script record # maybe we can have custom code/script to display the result $ perf script report -- 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/