Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754861AbbFEO14 (ORCPT ); Fri, 5 Jun 2015 10:27:56 -0400 Received: from mail.kernel.org ([198.145.29.136]:39582 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932980AbbFEN71 (ORCPT ); Fri, 5 Jun 2015 09:59:27 -0400 Date: Fri, 5 Jun 2015 10:59:20 -0300 From: Arnaldo Carvalho de Melo To: "Wangnan (F)" Cc: Ingo Molnar , Alexei Starovoitov , pi3orama , "linux-kernel@vger.kernel.org" , Adrian Hunter , 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 , Alexei Starovoitov Subject: Re: [GIT PULL 0/6] perf/core improvements and fixes Message-ID: <20150605135920.GI32707@kernel.org> References: <20150604054854.GA10969@gmail.com> <556FEB32.8040909@huawei.com> <20150604072153.GA18983@gmail.com> <557021D3.7070900@huawei.com> <20150604124033.GA10580@gmail.com> <0108CD89-BFFA-4A68-90AE-A34597777641@163.com> <20150604140412.GB14445@gmail.com> <55707B3F.2070704@plumgrid.com> <20150605064114.GA18341@gmail.com> <5571636F.1020403@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5571636F.1020403@huawei.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3381 Lines: 108 Em Fri, Jun 05, 2015 at 04:53:03PM +0800, Wangnan (F) escreveu: > On 2015/6/5 14:41, Ingo Molnar wrote: > >* Alexei Starovoitov wrote: > >>On 6/4/15 7:04 AM, Ingo Molnar wrote: > >In fact I'm NAK-ing the whole .o based interface until the .c interface is made > >the _primary_ one and works well and until I see that you have thought through > >basic usability questions... > OK. Let's start making a nice UI. > At this stage, what about wrapping current clang and llc workflow into perf, > let it call them to compile '.c' scripts? This is the way 'perf annotate' > using > objdump. I can do this job, but firstly I'd like to know people's opinion on Right, no need for, at a first step, to save this into a cache, or use libraries, etc, just automate the bpf.c into bpf.o, load it and use it as an event. > it, and the value of the wrapper if Alexei Starovoitov's dynamic compiler > shared object is coming. No need to wait for that, when it comes we can use it, but Ingo established as the door for this to be accepted is that we could use: perf record -e foo.c usleep Right? > Following functions will be added: > > - perf searches clang and llc under current $PATH, Good for a first step > - Users are allowed to pass the position of those programs, > if perf failed to find the automatically, I would leave all this configurabilty for later, stating that it has to be in the PATH should be ok for a first step. > - Users are allowed to pass extra compiling options to clang and llc, like > include directories, For later too? > - 'perf record' automatically calls them if a '.c' is passed using > '--event'. Right. > - 'perf bpf compile' command will be added to compile a '.c' find into > '.o', for later? I.e. 'perf record -e foo.c usleep' could start by generating the foo.o and not deleting it, so: perf record -e foo.c usleep Followed by: perf record -e foo.o usleep Would work, the later would be like a quick hack so that we could have access to a pre-compiled foo.o quickly, at this introductory stage. > Further, basic header files should be shipped with kernel headers. > > User interface update: > > - --llc, --clang, --llc-opt and --clang-opt option will be added to 'perf > record' > to indicate the position and extra options to them. Ideally they can be > leave > blank. Couldn't this be left to a section in a .perfconfig file to avoid having so many command line options? We could have one of those files per "project", after we add a --config option to 'perf record', to override whatever it finds in the config file search it already does, i.e.: [clang] path = /a/b/clang opt = -a -b -c -d [llc] path = /d/e/llc opt = -r -t -y -u But even this can be left for a second step. > - 'perf bpf compile' will be added. > One problem I can find is that, the wrapper will make perf depend on > llvm. I don't think the compiler will be deployed in production > environments... And also, the embedded case... Well, we can always build a subset of perf, using the command line options to disable certain features. - Arnaldo -- 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/