linux-kernel - RE: [Ptools-perfapi] [perfmon2] [PATCH] perf

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 22 Jan 2010 12:52:51 -0600
From:	"John  McCalpin" <mccalpin@...c.utexas.edu>
To:	'Peter Zijlstra' <peterz@...radead.org>
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)

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@...radead.org] 
Sent: Friday, January 22, 2010 11:42 AM
To: John McCalpin
Cc: 'Dan Terpstra'; eranian@...gle.com; linux-kernel@...r.kernel.org; ptools-perfapi@...s.utk.edu; perfmon2-devel@...ts.sf.net; fweisbec@...il.com; paulus@...ba.org; mingo@...e.hu; 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.