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

Groups > linux.kernel > #1433705

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

Show all headers | View raw

On Wed, Jun 29, 2016 at 06:35:12PM +0800, Wangnan (F) wrote:
> 
> 
> On 2016/6/29 18:15, Hekuang wrote:
> >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.

you'll see ~1Gb .so when llvm is compiled with debug info.

$ ls -lh libbcc.so.0.1.8
38M Jun 29 07:40 libbcc.so.0.1.8

and that includes full clang, llvm and two bcc front-ends.
llvm alone is 14M
that is perfectly acceptable even for a phone.

> >
> >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.
> >
> 
> Not userspace BPF. There would no userspace BPF if we choose two
> .c approach. We can compile user space part to a shared library,
> then make perf load it like a perf plugin. We can even glue BPF.o
> and native.o into one file with linker trick, then let's push it
> into smart phone use adb push... Oh, no, not only perf and the
> two (or one) objects. a dynamic perf requires more than 30
> libraries, we need to push them too.

that's a way as well, but I don't see why you need to combine two .o
loading bpf.o and native.o independently is easier, no?

> >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.
> >
> 
> Yes. The problem we consider now is interface. Before we can use
> llvm library on smartphone, shall we maintain a '.o + .so' interface
> separatly?

what's stopping using llvm on a phone now?

Back to linux.kernel | Previous | Next — Previous 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