From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751544AbcF2KRS (ORCPT ); Wed, 29 Jun 2016 06:17:18 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:2926 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbcF2KRR (ORCPT ); Wed, 29 Jun 2016 06:17:17 -0400 Subject: Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script To: Alexei Starovoitov References: <1466940078-65581-1-git-send-email-hekuang@huawei.com> <20160626204806.GA34060@ast-mbp> <577263E9.6080806@huawei.com> <20160628145702.GA48906@ast-mbp.thefacebook.com> CC: , , , , , , , , , From: Hekuang Message-ID: <57739FB6.1050402@huawei.com> Date: Wed, 29 Jun 2016 18:15:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160628145702.GA48906@ast-mbp.thefacebook.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.110.55.166] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57739FC4.0012,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d8169ba3785ff367b7b4d9cf0f99c04c Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.