lkml.org 
[lkml]   [2015]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs.


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




    \
     
     \ /
      Last update: 2015-05-26 08:41    [W:4.492 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site