Re: [RFC 00/13] perf_env/CPU socket reorg/fixes

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

Em Thu, Sep 10, 2015 at 11:19:06AM +0200, Jiri Olsa escreveu:
> On Wed, Sep 09, 2015 at 04:50:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > 	Please take a look at these changes to fix the problems reported by
> > Wang Nan wrt accesses to the cpu_topology_map information.
> > 
> > 	The fixes are present on these following two csets:
> > 
> >   perf event: Use machine->env to find the cpu -> socket mapping
> >   perf report: Do not blindly use env->cpu[al.cpu].socket_id
> > 
> > 	The rest are fixes made while working on this, infrastructure to enable
> > the fixes, reverts for things that ended up not being necessary and some
> > cleanups.
> > 
> > 	It is available at:
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/env
> > 
> > 	Please let me know if I can have your Acked-by, Tested-by or
> > Reviewed-by.
> 
> perf_env holds the data for perf.data session.. is the plan to keep

No, perf_env holds the data for the environment where samples were
taken.

It is needed to generate a perf.data file, and also now is needed to map
cpu -> socket_id, be it in a live session, where no perf.data file, nor
perf_session stuff is used (perf trace, I keep meaning to do the 'perf
top' conversion away from perf_session, others in the future).

I.e. perf_event__preprocess_sample() doesn't have to know if the samples
were freshly taken or if they come from another machine, possibly of a
different architecture.

> it like this, or it's to be used in some other way? Moving it out of
> session/header real suggest that.. just asking ;-)

They are already used in another way, i.e. we need to have that mapping
of cpu -> socket_id, to stop reading /sys/ to figure that out. I.e.
perf_env is, among other sampling/tracing environment, a cache of that
info, taken at perf.data generation time or at tool start time, if that
info is needed (i.e. if we use "socket" in -s).

- Arnaldo