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 for Android: free password hash cracker in your pocket

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

Message-ID: <1270044116.1616.26.camel@laptop>
Date:	Wed, 31 Mar 2010 16:01:56 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	Lin Ming <ming.m.lin@...el.com>, 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 Tue, 2010-03-30 at 15:12 -0700, Corey Ashford wrote:
> 
> > Initially I'd not allow per-pmu-per-task contexts
> > because then things like perf_event_task_sched_out() would get rather
> > complex.
> 
> Definitely.  I don't think it makes sense to have per-task context on 
> nest/uncore PMUs.  At least we haven't found any justification for it.

For uncore no, but there is also the hw-breakpoint stuff that is being
presented as a pmu, for those it would make sense to have a separate
per-task context.

But doing multiple per-task contexts is something for a next step
indeed.

> > For RR we can move away from perf_event_task_tick and let the pmu
> > install a (hr)timer for this on their own.
> 
> This is necessary I think, because of the access time for some of the PMU's.  I 
> wonder though if it should, perhaps optionally, be off-loaded to a high-priority 
> task to do the switching so that access latency to the PMU can be controlled.
> 
> As I mentioned when we met, some of the Wire-Speed processor nest PMU control 
> registers are accessed via SCOM, which is an internal, 200 MHz serial bus.  We 
> are being quoted ~525 SCOM bus ticks to do a PMU control register access, which 
> comes out to about 2.5 microseconds.  If you figure 5 accesses to rotate the 
> events on a PMU, that's a minimum of 12.5 microseconds. 

Yeah, you mentioned that.. for those things we need some changes anyway,
since currently we install per-cpu counters using IPIs and expect the
pmu::enable() method to be synchronous (it has a return value). It would
be totally unacceptable to do 2.5ms pokes with IRQs disabled.

The RR thing would be the easiest to solve, just let the timer wake up a
thread instead of doing the work itself, that's fully isolated to how
the pmu chooses to implement that. The above mentioned issue however
would be much more challenging to fix nicely.



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