Re: perf & rasd integration plan

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

Em Mon, Oct 06, 2014 at 09:53:49PM +0200, Borislav Petkov escreveu:
> On Mon, Oct 06, 2014 at 04:12:27PM -0300, Arnaldo Carvalho de Melo wrote:
> > Right, and it is being a great exercise, thanks for the patience so far
> > ;-)
> 
> I know, this is your secret agenda to keep me at bay working on this! :-P
> 
> > Looking at those ifdefs we see things that are specific to tools/perf/,
> > like perf_evsel having a struct hists embedded... I.e. that is of no
> > interest whatsoever (so far) to rasd, and in turn pulls other object
> > files.
> > 
> > So I think that right now we need to look at those ifdefs and go on
> > making what is in tools/perf/util/ stop using it somehow, so that what
> > then gets moved to tools/lib/api/perf/ (I guess this is where it should
> > be, opinions?) have that sorted out.

> > I.e. what goes to tools/lib/api/perf/ is what is common to the needs of
> > tools/perf/ and rasd (wherever it may roam).

> > Perhaps something like I did for sock/inet_sock/inet_connection_sock
> > ages ago... I.e. the tools that want a hists will have a 

> > struct hists_evsel {
> > 	struct perf_evsel evsel;
> > 	struct hists	  hists;
> > };

> > etc.

> > Experimenting with that, as it is the only thing ifdefed out in rasd's
> > copy of evsel.h...
 
> Right, this all reads like it is going in the right direction but the
> more important question IMO is are we doing a libperf or are we still
> doing tools/lib/api/perf/ of single object files to which people can
> link?

My preference would be for single object files, but the pressure to have
a written in stone library seems to just build up...
 
> Because if it is the second - and it sounds to me like it is - how do
> you propose we link with external projects? IOW, if I want to have rasd
> build *without* the kernel tree, is a simple
 
> cp -r tools/lib/api/ <my_project>/path/to/perf/lib/
 
> work?

It should, no matter if we end up with a library.

What I'm doing these days to test if perf builds on multiple distros is:

#!/bin/sh
remotebuild() {
	target=$1
	perfpkg=$2
  	cmd="rm -rf ${perfpkg} ; tar xf ${perfpkg}.tar.gz && cd ${perfpkg} && rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf && make -C tools/perf O=/tmp/build/perf install && make -C tools/perf build-test"
	scp ${perfpkg}.tar.gz gita@${target}:. && \
  	ssh gita@${target} "${cmd}"
}

targets="fedora14 opensuse12.3 fedora19 ubuntu13.10"
perfpkg=perf-3.17.0-rc4

for target in ${targets} ; do
	remotebuild ${target} ${perfpkg}
done

After doing a 'make perf-targz-src-pkg'

I.e. no kernel sources involved on the machines where I build test.

IOW, it is untangled from the kernel sources. As tools/lib/api/ should
as well.

> I mean, I don't know and I'm just asking. Is that the proposed way? Are
> we fine with that? Do we want something different, maybe even a lib? Is
> it time for a lib even?

Well, the rasd experience is serving to show areas where there is
unnecessary entanglement (hists inside perf_event, etc, the ifdefs you
put in place).

I'm working to remove the ones that are in rasd.c, aiming to have a
tools/lib/api/ tree that can be used to build rasd and tools/perf/.

What I don't want to do is to simply straight more
tools/perf/util/evlist.c to tools/lib/api/perf/, some untanglement work
is needed.
 
> Because the whole perf functionality is being cravingly ogled by other
> users - I know Matt wants it for cache QoS or whatever it is called and
> there are probably a whole lot of projects which would like to process
> events programatically in userspace.
> 
> So what I'm saying is, we probably should have a nice clean way
> to be able to share that code with external projects instead of
> external projects duplicating and building a whole library around
> perf_event_open() and the likes...

Agreed, hopefully we'll get that, finally.
 
> Just a couple of thoughts...
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --