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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150910141355.GA23511@kernel.org>
Date:	Thu, 10 Sep 2015 11:13:55 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Kan Liang <kan.liang@...el.com>, Ingo Molnar <mingo@...nel.org>,
	linux-kernel@...r.kernel.org,
	Adrian Hunter <adrian.hunter@...el.com>,
	Borislav Petkov <bp@...e.de>, David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Stephane Eranian <eranian@...gle.com>,
	Wang Nan <wangnan0@...wei.com>
Subject: Re: [RFC 00/13] perf_env/CPU socket reorg/fixes

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/