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.
    Em Wed, May 20, 2015 at 09:23:50AM +0900, Namhyung Kim escreveu:
    > On Tue, May 19, 2015 at 01:40:40PM -0300, 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:
    > > > 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.

    > I was thinking about something similar for SDT. I think that it'll
    > eventually handle ELF files as an event somehow, no? Maybe we need to
    > add ".bpf" suffix?

    Well, if both are ELF files, then probably they will have something that
    is unique to them, like perhaps some init function, or some section name
    that can be used to disambiguate, no?

    > > <SNIP>
    > >
    > > > > > 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?
    > >
    > > 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.
    >
    > Ah, okay. So 'perf script <xxx>' is same as 'perf script record <xxx> -o- | \
    > perf script report <xxx> -i-', right?

    Something like that, but without two commands spawned using pipes for
    communication.

    > > Look at:
    > >
    > > [acme@ssdandy linux]$ ls -la ~/libexec/perf-core/scripts/perl/bin/
    > > total 64
    > > drwxr-xr-x. 2 acme acme 4096 May 19 11:53 .
    > > drwxr-xr-x. 4 acme acme 4096 May 19 11:53 ..
    > > -rwxr-xr-x. 1 acme acme 78 May 19 11:53 check-perf-trace-record
    > > -rwxr-xr-x. 1 acme acme 132 Jan 6 11:36 check-perf-trace-report
    > > -rwxr-xr-x. 1 acme acme 109 May 19 11:53 failed-syscalls-record
    > > -rwxr-xr-x. 1 acme acme 241 May 19 11:53 failed-syscalls-report
    > > -rwxr-xr-x. 1 acme acme 83 May 19 11:53 rw-by-file-record
    > > -rwxr-xr-x. 1 acme acme 232 May 19 11:53 rw-by-file-report
    > > -rwxr-xr-x. 1 acme acme 135 May 19 11:53 rw-by-pid-record
    > > -rwxr-xr-x. 1 acme acme 114 May 19 11:53 rw-by-pid-report
    > > -rwxr-xr-x. 1 acme acme 135 May 19 11:53 rwtop-record
    > > -rwxr-xr-x. 1 acme acme 398 May 19 11:53 rwtop-report
    > > -rwxr-xr-x. 1 acme acme 75 May 19 11:53 wakeup-latency-record
    > > -rwxr-xr-x. 1 acme acme 133 May 19 11:53 wakeup-latency-report
    > > -rwxr-xr-x. 1 acme acme 160 Jan 6 13:05 workqueue-stats-record
    > > -rwxr-xr-x. 1 acme acme 136 Jan 6 13:05 workqueue-stats-report
    > > [acme@ssdandy linux]$
    > >
    > > 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 :-)
    >
    > IIRC there's a patch posted to support C for scripting.
    >
    > https://lkml.org/lkml/2014/5/22/13

    Lemme look at it... Yeah, that is part of what needs to be done, i.e.
    somehow we need to get the .c "script", build it and connect it to the
    perf tool.

    > Are you saying about it? A rough idea is that it'd be nice to have a
    > kind of this report/display code in a section of the bpf file itself.

    Exactly. All in one file, parts of it built for specific purposes and
    loaded in each needed way, then all gets connected.

    - Arnaldo


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