[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1264182121.4283.1549.camel@laptop>
Date: Fri, 22 Jan 2010 18:42:01 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: John McCalpin <mccalpin@...c.utexas.edu>
Cc: 'Dan Terpstra' <terpstra@...s.utk.edu>,
"eranian@...gle.com" <eranian@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ptools-perfapi@...s.utk.edu" <ptools-perfapi@...s.utk.edu>,
"perfmon2-devel@...ts.sf.net" <perfmon2-devel@...ts.sf.net>,
"fweisbec@...il.com" <fweisbec@...il.com>,
"paulus@...ba.org" <paulus@...ba.org>,
"mingo@...e.hu" <mingo@...e.hu>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [Ptools-perfapi] [perfmon2] [PATCH] perf_events: AMD event
scheduling (v1)
On Fri, 2010-01-22 at 11:33 -0600, John McCalpin wrote:
> * Think of the system as having four performance monitors per core
> *plus* four performance monitors for the "shared" structures on the
> chip (L3, crossbar, HyperTransport links, memory controllers).
Would have been nice to have them as a separately addressable pmu
instead of shadowing the logical cpu's pmu.
But that's all ancient history of course..
> There is an additional hazard when working with early K8 processors --
> a hardware bug causes the counts of all shared counters to be reset to
> zero any time any shared register is programmed. This makes
> "protecting" users somewhat more difficult....
Could you qualify early k8 a bit more, it shouldn't be hard to add a
quirk for a specific set of cpus to read/reset all counters before
writing to the shared pmu.
--
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/
Powered by blists - more mailing lists