Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751553AbbEZGYR (ORCPT ); Tue, 26 May 2015 02:24:17 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:45472 "EHLO szxga01-in.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751085AbbEZGYQ (ORCPT ); Tue, 26 May 2015 02:24:16 -0400 Message-ID: <5564113B.1000406@huawei.com> Date: Tue, 26 May 2015 14:22:51 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexei Starovoitov , Arnaldo Carvalho de Melo , Namhyung Kim CC: , , , , , , , , , , Subject: Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs. 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> <555BA112.6090505@plumgrid.com> In-Reply-To: <555BA112.6090505@plumgrid.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3875 Lines: 103 On 2015/5/20 4:46, Alexei Starovoitov wrote: > On 5/19/15 9:40 AM, 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. > > agree. 'bpf:' prefix is redundant. > To me the following syntax is fine: > perf record --event bpf_file.o > > In the future it can support automatically: > perf record --event bpf_file.c > > Wang, thoughts? > After reading the full thread I think we finally agree that the user interface should be perf record --event bpf_file.o for event filtering case. I'll do this in next version. Thank you. >>> 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. > > if you're proposing to do something like: > perf script bpf_file.c > that will do event creation, filtering, aggregation, reporting > and printing results, then it's fine. > This is pretty much what I thought 'perf bpf run' will do. > >> 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 :-) > > not sure that's doable. The task (perf) that loaded the program in the > step one should be still alive when 2nd part is running. > For 'perf bpf run' use case, the whole record/report split is > artificial. There is no need for perf.data. > In my mind 'perf bpf run file.c' suppose to quickly compile .c, > hook into kernel, collect and print something, then Ctrl-C of > 'perf bpf run' should automatically stop everything. > No perf.data anywhere. It should be quick single step > tool for live debugging. > At the same time 'perf record --event bpf_file.o' plus generic > 'perf report' model works very well as well. > They are different use cases. > > I guess I'm saying let's not get too much ahead of ourselves ;) > I think Wang's current patchset is close enough to make > 'perf record --event bpf_file.o' to be useful. > Let's take this first step. > -- 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/