linux-kernel - Re: [RFC] perf_events: support for uncore a.k.a. nest units

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]

Date:	Tue, 30 Mar 2010 09:49:52 -0700
From:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
To:	Lin Ming <ming.m.lin@...el.com>
CC:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...glemail.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Xiao Guangrong <xiaoguangrong@...fujitsu.com>,
	Dan Terpstra <terpstra@...s.utk.edu>,
	Philip Mucci <mucci@...s.utk.edu>,
	Maynard Johnson <mpjohn@...ibm.com>,
	Carl Love <cel@...ibm.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>
Subject: Re: [RFC] perf_events: support for uncore a.k.a. nest units

On 03/30/2010 12:42 AM, Lin Ming wrote:
> Hi, Corey
>
> How is this going now? Are you still working on this?
> I'd like to help to add support for uncore, test, write code or anything
> else.
>
> Thanks,
> Lin Ming

I haven't been actively working on adding infrastructure for nest PMUs 
yet.  At the moment we are working on supporting nest events for IBM's 
Wire-Speed processor, using the current infrastructure, because of the 
time limitations.  Using the existing infrastructure is definitely not 
ideal, but for this processor, it's workable.

There are still a lot of issues to solve for adding this infrastructure:

1) Does perf_events need a new context type (in addition to per-task and 
per-cpu)?  This is partly because we don't want to be mixing the 
rotation of CPU-events with nest events.  Each PMU really ought to have 
its own event list.

2) How do we deal with accessing PMU's which require slow access methods 
(e.g. internal serial bus)?  The accesses may need to be placed on 
worker threads so that they don't affect the performance of context 
switches and system ticks.

3) How exactly do we represent the PMU's in the pseudofs (/sys or 
/proc)?  And how exactly does the user specify the PMU to perf_events?
Peter Zijlstra and Stephane Eranian both recommended opening the PMU 
with open() and then passing the resulting fd in through the 
perf_event_attr struct.

4) How do we choose a CPU to do the housekeeping work for a particular 
nest PMU.  Peter thought that user space should still specify the it via 
open_perf_event() cpu parameter, but there's also an argument to be made 
for the kernel choosing the best CPU to handle the job, or at least make 
it optional for the user to choose the CPU.

I'm sure there are other issues as well.  If you'd like to start working 
on some (or all!) of these, you are more than welcome to.  I think we 
need to toss around some more ideas before committing much to code at 
this point.

- Corey
--
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/