Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752879AbbFDKGu (ORCPT ); Thu, 4 Jun 2015 06:06:50 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:7195 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751235AbbFDKGm (ORCPT ); Thu, 4 Jun 2015 06:06:42 -0400 Message-ID: <557021D3.7070900@huawei.com> Date: Thu, 4 Jun 2015 18:00:51 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ingo Molnar CC: Arnaldo Carvalho de Melo , , Adrian Hunter , Alexei Starovoitov , Brendan Gregg , Daniel Borkmann , "David Ahern" , He Kuang , Jiri Olsa , Kaixu Xia , Madhavan Srinivasan , Masami Hiramatsu , Michael Ellerman , Namhyung Kim , Peter Zijlstra , , Sukadev Bhattiprolu , "Zefan Li" , Arnaldo Carvalho de Melo , Alexei Starovoitov Subject: Re: [GIT PULL 0/6] perf/core improvements and fixes References: <1433371238-14572-1-git-send-email-acme@kernel.org> <20150604054854.GA10969@gmail.com> <556FEB32.8040909@huawei.com> <20150604072153.GA18983@gmail.com> In-Reply-To: <20150604072153.GA18983@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3573 Lines: 94 On 2015/6/4 15:21, Ingo Molnar wrote: > * Wangnan (F) wrote: > >> On 2015/6/4 13:48, Ingo Molnar wrote: >>> * Arnaldo Carvalho de Melo wrote: >>> >>>> Hi Ingo, >>>> >>>> Please consider applying. >>>> >>>> One of the next requests probably will have the eBPF work by Wang Nan, >>>> but I am still going thru it and want to test it thoroughly. >>>> >>>> BTW: Have you looked at it lately? It is at: >>>> >>>> http://lkml.kernel.org/r/1433144296-74992-1-git-send-email-wangnan0@huawei.com >>>> >>>> Super summary from the above cover letter: >>>> >>>> --------------------- >>>> It enables 'perf record' to filter events using eBPF programs like: >>>> >>>> # perf record --event bpf-file.o sleep 1 >>>> >>>> Events are selected and filtered according to definitions in bpf-file.o. >>> Looks useful, but I think the UI needs one more tweak: could you fix it to be able >>> to filter based on the eBPF _source_ file, not just the object file? >>> >>> People want to tweak such filters as they profile, so we should use the eBPF >>> source code as the primary interface. We can compile it internally to the .o just >>> fine. The .o file is a totally uninteresting intermediate product in itself. >>> >>> I.e. we need to first think through such profiling workflows from beginning to end >>> before allowing them upstream. >> In a private mail Alexei Starovoitov disscussed with me about this. He said that >> he is working on a shared object which can compile C program into BPF bytecode >> on the fly. After he done his work, I think perf can support dtrace-like >> profiling that, users will be able to feed source code to perf directly on >> cmdline. He said he can release it on June. I added him to the CC-list. >> >> However I think the '.o' intermediate is still needed. [...] > So how do you generate the .o? Why cannot the tool, if it sees that the filter > parameter is eBPF source code, do that automatically? I think compiling on the fly is our goal, and Alexei is working on it. However, it looks like some limitations are still exist. For example, the BPF program may require the definition of kernel structure for it to derefrernce struct pointers. Therefore, the machine on which compiling occures should have kernel header and configuration installed. However, most of production environment doesn't have them for security and reasons. I think BPF should be used to profile not only development environment but also production systems. If we only concern development systems, why not recompiling kernel with stub core or using kProbe modules? What about this: Give perf the ability to generate the '.o' file (to memory or dump to a real file) on development environment. If we are willing to profiling that system, we can make load the generated object into kernel and start trace by (perf record --event bpf_file.c ...). If we are willing to profile systems on which the compiling environment is missing, we can make perf to create a '.o' file (perf bpf compile bpf_file.c -o bpf_file.o) then copy it onto target environment, use perf record --event bpf_file.o ... to filter events. Thank you. > I.e. you are making the user jump through hoops for no good reason - that's a bad > UI and a bad workflow. Please don't do that! > > Thanks, > > Ingo -- 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/