lkml.org 
[lkml]   [2010]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [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.

\
 
 \ /
  Last update: 2010-01-22 19:55    [W:0.052 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site