Subject: Re: [RFC PATCH 0/4] perf tools: Use the new ability of eBPF programs
 to access hardware PMU counter
To: xiakaixu <xiakaixu@huawei.com>
References: <1440672142-89311-1-git-send-email-xiakaixu@huawei.com>
 <55E10AC1.1000706@plumgrid.com> <55E115A3.8030506@huawei.com>
Cc: davem@davemloft.net, daniel@iogearbox.net, acme@kernel.org,
        mingo@redhat.com, a.p.zijlstra@chello.nl,
        masami.hiramatsu.pt@hitachi.com, jolsa@kernel.org,
        linux-kernel@vger.kernel.org, wangnan0@huawei.com, pi3orama@163.com
From: Alexei Starovoitov <ast@plumgrid.com>
Message-ID: <55E11C15.5050002@plumgrid.com>
Date: Fri, 28 Aug 2015 19:42:29 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E115A3.8030506@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1798
Lines: 33

On 8/28/15 7:14 PM, xiakaixu wrote:
> Right, this is just a little example. Actually, I have tested this
> ability on kernel side and user space side, that is kprobe and uprobe.

great to hear.

> At this time i wish to get your comment on the current chosen implementation.
> Now the struct perf_event_map_def is introduced and the user can directly
> define the struct perf_event_attr, so we can skip the parse_events process
> and call the sys_perf_event_open on the events directly. This is the most
> simple implementation, but I am not sure it is the most appropriate.

I think it's a bit kludgy. You are trying to squeeze more and more
information into sections and pass them via elf.
It worked for samples early on, but now it's time to do better.
Like in bcc we just write normal C and extract all necessary information
by looking at C via clang:rewriter api. I think it's a cleaner approach.
In our use case we can compile on the host, so no intermediate files,
no elf files. If you have to cross-compile you can still use the same
approach and let llvm generate .o and emit all extra stuff as another
configuration file (say in .json), then let host load .o and use .json
to setup pmu events and everything else. It will work for higher number
of use cases, but at the end I don't see how you can avoid moving to
c+python or c+whatever approach, since static configuration (whether in
.json or in elf section) are not going to be enough. You'd need a
program in user space to deal with all the data that bpf program
in kernel is collecting.

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