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

[Wangnan (F)]

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.
>
> 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.

> 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?

> So what's your opinion on this?
>
> Thank you.