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?
