lkml.org 
[lkml]   [2015]   [May]   [19]   [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 Tue, May 19, 2015 at 06:10:33PM -0300, Arnaldo Carvalho de Melo wrote:
    > Em Tue, May 19, 2015 at 01:46:10PM -0700, Alexei Starovoitov escreveu:
    > > 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:
    > > >>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.
    >
    > I would say unnecessarily exposing an implementation detail :-)
    >
    > > To me the following syntax is fine:
    > > perf record --event bpf_file.o
    >
    > Agreed, for something pre-compiled.
    >
    > > In the future it can support automatically:
    > > perf record --event bpf_file.c
    >
    > Right, to compile it, then use the resulting bpf_file.o just like in the
    > first case, then, on another patch, cache it and next time just check
    > that the contents of the file hasn't changed, so the .o file can be
    > used, i.e. ccache like stuff.
    >
    > > Wang, thoughts?
    > >
    > > >>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.
    >
    > Agreed, that is what I think should be done, parts of what is in
    > bpf.file.c are related to the data collection, some are for filtering,
    > and parts are for reporting, etc.

    Looks great! :)

    >
    > This all should use infrastructure in perf for symbol resolving,
    > callcahins, etc.

    But then we need to stabilize libperf APIs IMHO. :)

    Thanks,
    Namhyung


    \
     
     \ /
      Last update: 2015-05-20 03:01    [W:4.183 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site