lkml.org 
[lkml]   [2016]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v2 00/26] perf tools: Support uBPF script
    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?

    \
     
     \ /
      Last update: 2016-06-29 15:21    [W:2.988 / U:0.752 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site