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:pet...@infradead.org] Sent: Friday, January 22, 2010 11:42 AM To: John McCalpin Cc: 'Dan Terpstra'; eran...@google.com; linux-ker...@vger.kernel.org; ptools-perf...@eecs.utk.edu; perfmon2-de...@lists.sf.net; fweis...@gmail.com; pau...@samba.org; mi...@elte.hu; da...@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. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
