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


Groups > linux.kernel > #1433652

Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script

From Hekuang <hekuang@huawei.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script
Date 2016-06-29 12:20 +0200
Message-ID <rPkL8-2Wd-15@gated-at.bofh.it> (permalink)
References <rOgqd-2jQ-3@gated-at.bofh.it> <rOpa9-7B9-3@gated-at.bofh.it> <rOZQl-6yo-11@gated-at.bofh.it> <rP2Ex-8qz-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


hi

在 2016/6/28 22:57, Alexei Starovoitov 写道:
>
>          return 0;
>   }
> @@ -465,7 +465,7 @@ EXPORT_SYMBOL_GPL(__bpf_call_base);
>    *
>    * Decode and execute eBPF instructions.
>    */
> -static unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn)
> +unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn)
> yes. that is good.
>
>>> Also I think the prior experience taught us that sharing code between
>>> kernel and user space will have lots of headaches long term.
>>> I think it makes more sense to use bcc approach. Just have c+py
>>> or c+lua or c+c. llvm has x86 backend too. If you integrate
>>> clang/llvm (bcc approach) you can compile different functions with
>>> different backends... if you don't want to embed the compiler,
>>> have two .c files. Compile one for bpf target and another for native.
> I still think that what two .c files without embeded llvm or
> one .c with embedded is a better way.
> You'll have full C that is fast on x86 or arm instead of
> executing things in ubpf.
> Or use py/lua wrappers. Equally easy.
>
Our goal is the same as you described, that to have one .c file
and embeded llvm into perf for compiling it to bpf target for
kernel and native for userspace.

But there's two problems we may encounter by this way on the
phone, which is the most common scenario our work focus on.

The first one is the size of bcc/llvm library. It's more than
800MB for libbcc.so and I guess the llvm part takes most of
them. Shortly we can run perf as a daemon after the
overwrite/control channel be merged (wangnan's recently patches),
such a huge memory consumption is not acceptable.

Second, I've browsed the bcc source briefly and see that there's
two frontend for loading .b and .c, we have to integrate the x86
backend for compiling bpf to native code. That's possible but we
still need extra works and it is not ready to use for now.

Then we have two other approaches, the first is as 'ubpf v2'
which uses one .c file and introduces bpf vm to perf, the second
is like you said, use two .c files and compile userspace bpf to
native code by using llvm externally.

Both the two ways are easy to implement, but we prefer the first
one between them because it uses one .c file which is the same as
our final approach, and it does not face the huge memory
consumption problem, finally, after we solve problems on embeded
llvm in perf and lower the memory consumption, we can keep the
user interface and replace the bpf vm to llvm
frontend+backend.

So what's your opinion on this?

Thank you.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH v2 00/26] perf tools: Support uBPF script He Kuang <hekuang@huawei.com> - 2016-06-26 13:30 +0200
  [RFC PATCH v2 21/26] bpf: Support bpf load/store boundary check for ubpf He Kuang <hekuang@huawei.com> - 2016-06-26 13:30 +0200
  [RFC PATCH v2 01/26] tools include: Adopt byte ordering macros from byteorder/generic.h He Kuang <hekuang@huawei.com> - 2016-06-26 13:30 +0200
  [RFC PATCH v2 12/26] perf bpf: Add libbpf-internal.h header file He Kuang <hekuang@huawei.com> - 2016-06-26 13:30 +0200
  [RFC PATCH v2 03/26] bpf: split __bpf_prog_run code into new file He Kuang <hekuang@huawei.com> - 2016-06-26 13:30 +0200
  [RFC PATCH v2 06/26] tools include: Add (atomic|atomic64)_add implementation from the kernel sources He Kuang <hekuang@huawei.com> - 2016-06-26 13:30 +0200
  Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-06-26 22:50 +0200
    Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script Hekuang <hekuang@huawei.com> - 2016-06-27 04:20 +0200
    Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script Hekuang <hekuang@huawei.com> - 2016-06-28 14:00 +0200
      Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-06-28 17:00 +0200
        Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script Hekuang <hekuang@huawei.com> - 2016-06-29 12:20 +0200
          Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script "Wangnan (F)" <wangnan0@huawei.com> - 2016-06-29 12:50 +0200
            Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-06-29 14:40 +0200
              Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script pi3orama <pi3orama@163.com> - 2016-06-29 15:10 +0200

csiph-web