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

[pi3orama]

发自我的 iPhone

> 在 2016年6月29日，下午8:37，Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> 写道：
> 
>> 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!