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

[Alexei Starovoitov]

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?