发自我的 iPhone
> 在 2016年6月29日，下午8:37，Alexei Starovoitov <alexei.starovoi...@gmail.com> 写道： > >> 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? Size is the only consideration now. If we can shrink LLVM library to less than 20MB then embedding libLLVM is really worth a try. We'll try to compile to arm64 tomorrow. I have seen some discussions on it so I think it would not be very hard. Thank you for your information!
