Messages in this thread | | | From | "John McCalpin" <> | Date | Fri, 22 Jan 2010 12:52:51 -0600 | Subject | RE: [Ptools-perfapi] [perfmon2] [PATCH] perf_events: AMD event scheduling (v1) |
| |
In the comments for perfctr's linux/drivers/perfctr/x86.c driver file, there is a note on this. From perfctr version 2.6.31, item (2) refers to this issue: /* * Multicore K8s have issues with northbridge events: * 1. The NB is shared between the cores, so two different cores * in the same node cannot count NB events simultaneously. * This can be handled by using perfctr_cpus_forbidden_mask to * restrict NB-using threads to core0 of all nodes. * 2. The initial multicore chips (Revision E) have an erratum * which causes the NB counters to be reset when either core * reprograms its evntsels (even for non-NB events). * This is only an issue because of scheduling of threads, so * we restrict NB events to the non thread-centric API. * * For now we only implement the workaround for issue 2, as this * also handles issue 1. * * TODO: Detect post Revision E chips and implement a weaker * workaround for them. */
I have gone back through the AMD Opteron Revision Guide for these processors http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf but I don't see any publicly disclosed errata that appear to be related to this issue.
Perhaps I will check it on my Athlon64FX system at home this weekend....
john
-----Original Message----- From: Peter Zijlstra [mailto:peterz@infradead.org] Sent: Friday, January 22, 2010 11:42 AM To: John McCalpin Cc: 'Dan Terpstra'; eranian@google.com; linux-kernel@vger.kernel.org; ptools-perfapi@eecs.utk.edu; perfmon2-devel@lists.sf.net; fweisbec@gmail.com; paulus@samba.org; mingo@elte.hu; davem@davemloft.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.
| |