Re: [GIT PULL 0/6] perf/core improvements and fixes

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Fri, Jun 05, 2015 at 04:53:03PM +0800, Wangnan (F) escreveu:
> On 2015/6/5 14:41, Ingo Molnar wrote:
> >* Alexei Starovoitov <ast@plumgrid.com> 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