Message-ID: <55447A7D.4000205@huawei.com>
Date:	Sat, 2 May 2015 15:19:25 +0800
From:	Wang Nan <wangnan0@...wei.com>
To:	Alexei Starovoitov <ast@...mgrid.com>, <davem@...emloft.net>,
	<acme@...nel.org>, <mingo@...hat.com>, <a.p.zijlstra@...llo.nl>,
	<masami.hiramatsu.pt@...achi.com>, <jolsa@...nel.org>
CC:	<lizefan@...nel.org>, <linux-kernel@...r.kernel.org>,
	<pi3orama@....com>, <hekuang@...wei.com>, <bgregg@...flix.com>,
	He Kuang <hekuang@...wei.com>
Subject: Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to
 load eBPF programs.

On 2015/5/1 12:37, Alexei Starovoitov wrote:
> On 4/30/15 3:52 AM, Wang Nan wrote:
>> This series of patches is an approach to integrate eBPF with perf.
>> After applying these patches, users are allowed to use following
>> command to load eBPF program compiled by LLVM into kernel:
>>
>>   $ perf bpf sample_bpf.o
>>
>> The required BPF code and the loading procedure is similar to Alexei
>> Starovoitov's libbpf in sample/bpf, with following exceptions:
>>
>>   1. The section name are not required leading with 'kprobe/' or
>>      'kretprobe/'. Without such leading, any valid C var name can be use.
>>
>>   2. A 'config' section can be provided to describe the position and
>>      arguments of a program. Syntax is identical to 'perf probe'.
>>
>> An example is pasted at the bottom of this cover letter. In that
>> example, mybpfprog is configured by string in config section, and will
>> be probed at __alloc_pages_nodemask. sample_bpf.o is generated using:
>>
>>   $ $CLANG -I/usr/src/kernel/include -I/usr/src/kernel/usr/include -D__KERNEL__ \
>>      -Wno-unused-value -Wno-pointer-sign \
>>      -O2 -emit-llvm -c sample_bpf.c -o -| $LLC -march=bpf -filetype=obj -o \
>>      sample_bpf.o
>>
>> And can be loaded using:
>>
>>   $ perf bpf sample_bpf.o
>>
>> This series is only a limited functional. Following works are on the
>> todo list:
>>
>>   1. Unprobe kprobe stubs used by eBPF programs when unloading;
>>
>>   2. Enable eBPF programs to access local variables and arguments
>>      by utilizing debuginfo;
>>
>>   3. Output data in perf way.
>>
>> In this series:
>>
>> Patch 1/22 is a bugfix in perf probe, and may be triggered by following
>> patches;
>>
>> Patch 2-3/22 are preparation, add required macros and syscall
>> definition into perf source tree.
>>
>> Patch 4/22 add 'perf bpf' command.
>>
>> Patch 5-20/22 are labor works, which parse the ELF object file, collect
>> information in object files, create maps needed by programs, link map
>> and programs, config programs and load programs into kernel.
>>
>> Patch 21-22/22 are the final work. Patch 21 creates kprobe points which
>> will be used by eBPF programs, patch 22 creates perf file descriptors
>> then attach eBPF programs on them.
> 
> I'm very happy to see this work. Looks great. All patches are impressively clean and concise.
> I think patches 1-3 are ready to go into Arnaldo's perf tree right now.
> 4 and above are clean and polished, but probably need to go into
> some 'staging area' like a branch of perf tree, since I suspect the
> user interface may change a little in the coming months and it's
> a bit too early to expose 'perf bpf' command to every perf user ?
> Arnaldo, Ingo, what do you guys think should be the arrangement?
> 'perf/bpf' branch in acme/linux.git or in tip/tip.git ?
> 
> I have few comments for patches 18 and 19, but let's figure out
> the long term plan first.
> 

Hi,

Very happy to see your and other's positive feedbacks. I'm also interested in
how these patches can be merged into mainline. I'd like to continous send patches
to this list to let you all see my improvements, and let maintainers deside whether
and how to merge them.

Now we are also doing some backporting work to make eBPF patches to work for our
low version kernels. After that we will utilize eBPF in our profiling work.
I think this RFC series is only a start point to let us to use eBPF. Further requirements
should arise during our real work.

I'd like to do following works in the next version (based on my experience and feedbacks):

1. Safely clean up kprobe points after unloading;

2. Add subcommand space to 'perf bpf'. Current staff should be reside in 'perf bpf load';

3. Extract eBPF ELF walking and collecting work to a separated library to help others.

My collage He Kuang is working on variable accessing. Probing inside function body
and accessing its local variable will be supported like this:

 SEC("config") char _prog_config[] = "prog: func_name:1234 vara=localvara"
 int prog(struct pt_regs *ctx, unsigned long vara) {
    // vara is the value of localvara of function func_name
 }

And I want to discuss with you and others about:

 1. How to make eBPF output its tracing and aggregation results to perf?

Thanks!

> We're also working in parallel on creating a new tracing language
> that together with llvm backend can be used as a single shared library
> that can be called from perf or anything else.
> Then clang compilation step will be gone and programs can be run
> as 'perf bpf file.bpf'.
> 
> Thanks!
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists