Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1433652
| From | Hekuang <hekuang@huawei.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script |
| Date | 2016-06-29 12:20 +0200 |
| Message-ID | <rPkL8-2Wd-15@gated-at.bofh.it> (permalink) |
| References | <rOgqd-2jQ-3@gated-at.bofh.it> <rOpa9-7B9-3@gated-at.bofh.it> <rOZQl-6yo-11@gated-at.bofh.it> <rP2Ex-8qz-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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. 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. So what's your opinion on this? Thank you.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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