[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57708B22.7030406@huawei.com>
Date: Mon, 27 Jun 2016 10:10:42 +0800
From: Hekuang <hekuang@...wei.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
CC: <acme@...nel.org>, <peterz@...radead.org>, <mingo@...hat.com>,
<jolsa@...hat.com>, <brendan.d.gregg@...il.com>, <ast@...nel.org>,
<alexander.shishkin@...ux.intel.com>, <wangnan0@...wei.com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script
hi
在 2016/6/27 4:48, Alexei Starovoitov 写道:
> On Sun, Jun 26, 2016 at 11:20:52AM +0000, He Kuang wrote:
>> This patchset is based on Wang Nan's v1:
>> http://thread.gmane.org/gmane.linux.kernel/2203717/focus=2203707
>>
>> """
>> This patch set allows to perf invoke some user space BPF scripts on
>> some point. uBPF scripts and kernel BPF scripts reside in one BPF
>> object. They communicate with each other with BPF maps. uBPF
>> scripts can invoke helper functions provided by perf.
>>
>> At least following new features can be achieved based on uBPF
>> support:
>>
>> 1) Report statistical result:
>>
>> Like DTrace, perf print statistical report before quit. No need
>> to extract data using 'perf report'. Statistical method is
>> controled by user.
>>
>> 2) Control perf's behavior:
>>
>> Dynamically adjust period of different events. Policy is defined
>> by user.
>> """
>>
>> and modified by following the reviewers' suggestions.
>>
>> v1-v2:
>>
>> - Split bpf vm part out of kernel/bpf/core.c and link to it instead
>> of using ubpf library(Suggested by Alexei Starovoitov). And add
>> runtime bounds check just like ubpf library does.
> hmm. I don't think I suggested to hack bpf/core.c into separate file
> and compile it for userspace...
"""
Also ubpf was written from scratch with apache2, while perf is gpl,
so you can just link kernel/bpf/core.o directly instead of using external
libraries.
"""
This is your comment on ubpf v1 thread.
I thought you was suggesting to use code in kernel/bpf/core.o,
but because there're difference in __bpf_prog_run() between userspace
and kernel, for example the __bpf_call_base is used in kernel,
in userspace we get funcs from ubpf function list, we have to modify
the existing code in kernel/bpf/core.c.
I've got the source code of 'bcc' project, but it seems that bcc does not
involve bpf virtual machine, so if we do not use 'kernel/bpf/core.o' solution,
and can't use 'ubpf' because of the license reason, any other choices?
Thank you.
> 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.
>
>
Powered by blists - more mailing lists