From: Peter Zijlstra <peterz@infradead.org>
To: John McCalpin <mccalpin@tacc.utexas.edu>
Cc: "'Dan Terpstra'" <terpstra@eecs.utk.edu>,
"eranian@google.com" <eranian@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ptools-perfapi@eecs.utk.edu" <ptools-perfapi@eecs.utk.edu>,
"perfmon2-devel@lists.sf.net" <perfmon2-devel@lists.sf.net>,
"fweisbec@gmail.com" <fweisbec@gmail.com>,
"paulus@samba.org" <paulus@samba.org>,
"mingo@elte.hu" <mingo@elte.hu>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [Ptools-perfapi] [perfmon2] [PATCH] perf_events: AMD event scheduling (v1)
Date: Fri, 22 Jan 2010 18:42:01 +0100 [thread overview]
Message-ID: <1264182121.4283.1549.camel@laptop> (raw)
In-Reply-To: <CF3466DD76A94945B5723C073FE74B0A69E64117E6@MAIL02.austin.utexas.edu>
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.
next prev parent reply other threads:[~2010-01-22 17:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-22 10:43 [PATCH] perf_events: AMD event scheduling (v1) Stephane Eranian
2010-01-22 15:22 ` [perfmon2] " Dan Terpstra
2010-01-22 15:25 ` [Ptools-perfapi] " stephane eranian
2010-01-22 17:33 ` John McCalpin
2010-01-22 17:42 ` Peter Zijlstra [this message]
2010-01-22 18:52 ` John McCalpin
2010-01-25 14:20 ` Stephane Eranian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1264182121.4283.1549.camel@laptop \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mccalpin@tacc.utexas.edu \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sf.net \
--cc=ptools-perfapi@eecs.utk.edu \
--cc=terpstra@eecs.utk.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox