From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755984AbbESNpH (ORCPT ); Tue, 19 May 2015 09:45:07 -0400 Received: from mail.kernel.org ([198.145.29.136]:36189 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755697AbbESNpD (ORCPT ); Tue, 19 May 2015 09:45:03 -0400 Date: Tue, 19 May 2015 10:44:58 -0300 From: Arnaldo Carvalho de Melo To: Alexei Starovoitov Cc: Wang Nan , paulus@samba.org, a.p.zijlstra@chello.nl, mingo@redhat.com, namhyung@kernel.org, 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: <20150519134458.GC13946@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555A5D96.2070509@plumgrid.com> X-Url: http://acmel.wordpress.com 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 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