[PATCH 1/3] perf: Document enhanced event encoding for OFFCORE_MSR

Previous thread: [PATCH v4] ppc44x:PHY fixup for USB on canyonlands board by Rupjyoti Sarmah on Monday, November 29, 2010 - 6:13 am. (3 messages)

Next thread: GFS2: Pull request (fixes) by Steven Whitehouse on Monday, November 29, 2010 - 6:42 am. (1 message)
From: Andi Kleen
Date: Monday, November 29, 2010 - 6:12 am

Rebased on top of tip perf/perf-core with the new initcall sequence.
Now uses reference counts and kzalloc_node() to allocate the per node
data.
I dropped the patch that was already in tip.

-Andi

--

From: Andi Kleen
Date: Monday, November 29, 2010 - 6:12 am

From: Andi Kleen <ak@linux.intel.com>

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 tools/perf/Documentation/perf-list.txt |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt
index 399751b..22678d2 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -58,6 +58,13 @@ raw encoding of 0x1A8 can be used:
  perf stat -e r1a8 -a sleep 1
  perf record -e r1a8 ...
 
+Some special events on x86 encode additional data in the normally unused
+[32;63] bits of the raw value. This is particularly used for
+the OFFCORE_RESPONSE events on Intel Core i7.  The 16bit
+mask in the OFFCORE_RESPONSE register is put into bits [32;48].
+For example the OFFCORE_RESPONSE_0.ANY_DATA.ANY_CACHE_DRAM event
+is encoded as r00007f11004301b7.
+
 You should refer to the processor specific documentation for getting these
 details. Some of them are referenced in the SEE ALSO section below.
 
-- 
1.7.1

--

From: Andi Kleen
Date: Monday, November 29, 2010 - 6:12 am

From: Andi Kleen <ak@linux.intel.com>

Intel Nehalem/Westmere have a special OFFCORE_RESPONSE event
that can be used to monitor any offcore accesses from a core.
This is a very useful event for various tunings, and it's
also needed to implement the generic LLC-* events correctly.

Unfortunately this event requires programming a mask in a separate
register. And worse this separate register is per core, not per
CPU thread.

This patch adds:
- Teaches perf_events that OFFCORE_RESPONSE needs extra parameters.
The extra parameters are passed by user space in the unused upper
32bits of the config word.
- Add support to the Intel perf_event core to schedule per
core resources. This adds fairly generic infrastructure that
can be also used for other per core resources.
The basic code has is patterned after the similar AMD northbridge
constraints code.

Thanks to Stephane Eranian who pointed out some problems
in the original version and suggested improvements.

Cc: eranian@google.com
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 arch/x86/kernel/cpu/perf_event.c       |   70 +++++++++++
 arch/x86/kernel/cpu/perf_event_intel.c |  198 ++++++++++++++++++++++++++++++++
 include/linux/perf_event.h             |    2 +
 3 files changed, 270 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 817d2b1..a6754ea 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -93,6 +93,8 @@ struct amd_nb {
 	struct event_constraint event_constraints[X86_PMC_IDX_MAX];
 };
 
+struct intel_percore;
+
 #define MAX_LBR_ENTRIES		16
 
 struct cpu_hw_events {
@@ -128,6 +130,13 @@ struct cpu_hw_events {
 	struct perf_branch_entry	lbr_entries[MAX_LBR_ENTRIES];
 
 	/*
+	 * Intel percore register state.
+	 * Coordinate shared resources between HT threads.
+	 */
+	int				percore_used; /* Used by this CPU? */
+	struct intel_percore		*per_core;
+
+	/*
 	 * AMD specific bits
 	 */
 	struct ...
From: Peter Zijlstra
Date: Wednesday, December 1, 2010 - 7:26 am

You seem to have lost the needs_percore stuff.
--

Previous thread: [PATCH v4] ppc44x:PHY fixup for USB on canyonlands board by Rupjyoti Sarmah on Monday, November 29, 2010 - 6:13 am. (3 messages)

Next thread: GFS2: Pull request (fixes) by Steven Whitehouse on Monday, November 29, 2010 - 6:42 am. (1 message)