Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1258731 > unrolled thread

[GIT PULL 0/6] perf/ebpf basic integration

Back to article view | Back to linux.kernel

Contents

  [GIT PULL 0/6] perf/ebpf basic integration Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-10-29 12:20 +0100
    Re: [GIT PULL 0/6] perf/ebpf basic integration Ingo Molnar <mingo@kernel.org> - 2015-10-29 13:20 +0100
      Re: [GIT PULL 0/6] perf/ebpf basic integration Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-10-29 14:20 +0100

#1258731 — [GIT PULL 0/6] perf/ebpf basic integration

Hi Ingo,

	Please take a look at the changeset comments, I made notes in most of
them, this seems like a nice cutoff point to allow basic testing, by
developers, for the very basic integration of perf and ebpf, i.e. we can,
having a ready built object file, built with clang, be able to use it as a perf
event, passing it via -e/--event, etc.

	Wang has lots more in the queue and I intend to work on them till I get
all reviewed/tested/merged, i.e. in the immediate future.

	What do you think? Fair to get his smaller gulp now? Or do you want to
get it all the way with the code to get a .c file, build it, etc, that is
ready, but I haven't reviewed/tested yet?

	Ah, this is on top of what I sent to you via perf/core yesterday.

Thanks,

- Arnaldo

The following changes since commit 443f8c75e8d58d394b0e65b47e02e5cd8ed32b41:

  perf symbols: Fix endless loop in dso__split_kallsyms_for_kcore (2015-10-28 11:19:30 -0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-ebpf-for-mingo

for you to fetch changes up to 4edf30e39e6cff32390eaff6a1508969b3cd967b:

  perf bpf: Collect perf_evsel in BPF object files (2015-10-28 13:11:59 -0300)

----------------------------------------------------------------
perf/ebpf basic integration

Please see the changeset comments, but this is the very basic integration of
perf with libbpf that, given a .o file built for the 'bpf' target with clang,
will get it validated and loaded into the kernel via the sys_bpf syscall, which
can be seen using 'perf trace' to trace the whole thing looking just for the
bpf and perf_event_open syscalls:

  # perf trace -e bpf,perf_event_open perf record -g --event /tmp/foo.o -a
   362.779 ( 0.129 ms): perf/22408 bpf(cmd: 5, uattr: 0x7ffd4edb6db0, size: 48                           ) = 3
   384.192 ( 0.016 ms): perf/22408 perf_event_open(attr_uptr: 0x7ffd4edbace0, pid: -1, cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 5
   384.247 ( 0.038 ms): perf/22408 perf_event_open(attr_uptr: 0x37aedd8, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 5
   384.261 ( 0.007 ms): perf/22408 perf_event_open(attr_uptr: 0x37aedd8, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 5
   387.680 ( 3.413 ms): perf/22408 perf_event_open(attr_uptr: 0x3222f08, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 5
   387.688 ( 0.005 ms): perf/22408 perf_event_open(attr_uptr: 0x3222f08, pid: -1, cpu: 1, group_fd: -1, flags: FD_CLOEXEC) = 6
   387.693 ( 0.004 ms): perf/22408 perf_event_open(attr_uptr: 0x3222f08, pid: -1, cpu: 2, group_fd: -1, flags: FD_CLOEXEC) = 7
   387.698 ( 0.003 ms): perf/22408 perf_event_open(attr_uptr: 0x3222f08, pid: -1, cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 8
  ^C[ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.221 MB perf.data (2 samples) ]
  # perf script
  bash 18389 [002] 83446.412607: perf_bpf_probe:fork: (ffffffff8109be30)
                  29be31 _do_fork (/lib/modules/4.3.0-rc6+/build/vmlinux)
                  96d662 tracesys_phase2 (/lib/modules/4.3.0-rc6+/build/vmlinux)
                   bd56c __libc_fork (/usr/lib64/libc-2.17.so)
                   413b2 make_child (/usr/bin/bash)

  bash 18389 [002] 83447.227255: perf_bpf_probe:fork: (ffffffff8109be30)
                  29be31 _do_fork (/lib/modules/4.3.0-rc6+/build/vmlinux)
                  96d662 tracesys_phase2 (/lib/modules/4.3.0-rc6+/build/vmlinux)
                   bd56c __libc_fork (/usr/lib64/libc-2.17.so)
                   413b2 make_child (/usr/bin/bash)

  # perf evlist -v
  perf_bpf_probe:fork: type: 2, size: 112, config: 0x6cf, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD|RAW, disabled: 1, inherit: 1, mmap: 1, comm: 1, task: 1, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1
  #

More work is about to be reviewed, tested and merged that will allow the whole
process of going from a .c file to an .o file via clang, etc to be done
automagically. (Wang Nan)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

----------------------------------------------------------------
Wang Nan (6):
      perf tools: Make perf depend on libbpf
      perf ebpf: Add the libbpf glue
      perf tools: Enable passing bpf object file to --event
      perf tools: Create probe points for BPF programs
      perf tools: Load eBPF object into kernel
      perf bpf: Collect perf_evsel in BPF object files

 tools/build/Makefile.feature   |   6 +-
 tools/perf/MANIFEST            |   3 +
 tools/perf/Makefile.perf       |  21 ++-
 tools/perf/config/Makefile     |  19 ++-
 tools/perf/perf.c              |   2 +
 tools/perf/tests/make          |   4 +-
 tools/perf/util/Build          |   1 +
 tools/perf/util/bpf-loader.c   | 339 +++++++++++++++++++++++++++++++++++++++++
 tools/perf/util/bpf-loader.h   |  84 ++++++++++
 tools/perf/util/parse-events.c | 118 ++++++++++++++
 tools/perf/util/parse-events.h |   8 +
 tools/perf/util/parse-events.l |   3 +
 tools/perf/util/parse-events.y |  18 ++-
 13 files changed, 619 insertions(+), 7 deletions(-)
 create mode 100644 tools/perf/util/bpf-loader.c
 create mode 100644 tools/perf/util/bpf-loader.h
--
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/

[toc] | [next] | [standalone]

#1258747

* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Hi Ingo,
> 
> 	Please take a look at the changeset comments, I made notes in most of
> them, this seems like a nice cutoff point to allow basic testing, by
> developers, for the very basic integration of perf and ebpf, i.e. we can,
> having a ready built object file, built with clang, be able to use it as a perf
> event, passing it via -e/--event, etc.
> 
> 	Wang has lots more in the queue and I intend to work on them till I get
> all reviewed/tested/merged, i.e. in the immediate future.
> 
> 	What do you think? Fair to get his smaller gulp now? Or do you want to
> get it all the way with the code to get a .c file, build it, etc, that is
> ready, but I haven't reviewed/tested yet?
> 
> 	Ah, this is on top of what I sent to you via perf/core yesterday.

I'm fine with this, as long as this bit:

> More work is about to be reviewed, tested and merged that will allow the whole
> process of going from a .c file to an .o file via clang, etc to be done
> automagically. (Wang Nan)

... is treated as the primary interface. Very few people will use object files, so 
we need to integrate the whole life-time workflow, from instrumentation source 
code to perf output.

Thanks,

	Ingo
--
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/

[toc] | [prev] | [next] | [standalone]

#1258778

Em Thu, Oct 29, 2015 at 01:17:32PM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > 	Please take a look at the changeset comments, I made notes in most of
> > them, this seems like a nice cutoff point to allow basic testing, by
> > developers, for the very basic integration of perf and ebpf, i.e. we can,
> > having a ready built object file, built with clang, be able to use it as a perf
> > event, passing it via -e/--event, etc.

> > 	Wang has lots more in the queue and I intend to work on them till I get
> > all reviewed/tested/merged, i.e. in the immediate future.

> > 	What do you think? Fair to get his smaller gulp now? Or do you want to
> > get it all the way with the code to get a .c file, build it, etc, that is
> > ready, but I haven't reviewed/tested yet?

> > 	Ah, this is on top of what I sent to you via perf/core yesterday.
 
> I'm fine with this, as long as this bit:
 
> > More work is about to be reviewed, tested and merged that will allow the whole
> > process of going from a .c file to an .o file via clang, etc to be done
> > automagically. (Wang Nan)
 
> ... is treated as the primary interface. Very few people will use object files, so 
> we need to integrate the whole life-time workflow, from instrumentation source 
> code to perf output.

Sure, I'm doing the review/test now, but at the same time, stressing
that you _can_ shortcut all that and, having a suitable .o file, use all
the other perf features with it is also cool and something worth
pointing out.

To _have to_ produce a .o to use this is, of course, bad and shortly
will be done completely automatically in as a streamlined way as we can
conceive.

- Arnaldo
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web