Skip to contentSkip to conversation

perf: Add missing user space support for config1/config2 v2

PATCH In review Andi Kleen 2 participants 2 messages Apr 13, 2011 – Apr 22, 2011

Subsystems (2)
lore
Share & tools
lore

Andi Kleen

author
#0 lore raw

PATCH 1/1 perf: Add missing user space support for config1/config2 v2

From: Andi Kleen <[email protected]>

Updated version that avoids warning/-Werror on some gcc versions I didn't test initially. Ceterum censeo -Werror esse delendam.

-Andi

---

The offcore_msr perf kernel code was merged into 2.6.39-rc*, but the user space bits were not. This made it impossible to set the extra mask and actually do the OFFCORE profiling

This patch fixes this. It adds a new syntax ':' to raw events to specify additional event masks. I also added support for setting config2, even though that is not needed currently.

[Note: the original version back in time used , -- but that actually conflicted with event lists, so now it's :]

---
 tools/perf/Documentation/perf-list.txt |   11 +++++++++++
 tools/perf/util/parse-events.c         |   18 +++++++++++++++++-
 2 files changed, 28 insertions(+), 1 deletions(-)
tools/perf/Documentation/perf-list.txt +11 -0
index 7a527f7..5a43169 100644
@@ -61,6 +61,17 @@ raw encoding of 0x1A8 can be used:
 You should refer to the processor specific documentation for getting these
 details. Some of them are referenced in the SEE ALSO section below.
 
+Some raw events -- like the Intel OFFCORE events -- support additional 
+parameters. These can be appended after a ':'.
+
+For example on a multi socket Intel Nehalem:
+
+ perf stat -e r1b7:20ff -a sleep 1
+
+Profile the OFFCORE_RESPONSE.ANY_REQUEST with event mask REMOTE_DRAM_0 
+that measures any access to DRAM on another socket.  Upto two parameters can 
+be specified with additional ':'
+
 OPTIONS
 -------
 
tools/perf/util/parse-events.c +17 -1
index 952b4ae..783be64 100644
@@ -688,9 +688,25 @@ parse_raw_event(const char **strp, struct perf_event_attr *attr)
 		return EVT_FAILED;
 	n = hex2u64(str + 1, &config);
 	if (n > 0) {
-		*strp = str + n + 1;
+		str += n + 1;
 		attr->type = PERF_TYPE_RAW;
 		attr->config = config;
+		if (*str == ':') {
+			str++;
+			n = hex2u64(str, &config);
+			if (n == 0)
+				return EVT_FAILED;
+			attr->config1 = config;
+			str += n;
+			if (*str == ':') {
+				str++;
+				n = hex2u64(str + 1, &config);
+				if (n == 0)
+					return EVT_FAILED;
+				attr->config2 = config;
+			}
+		}	
+		*strp = str;
 		return EVT_HANDLED;
 	}
 	return EVT_FAILED;
Signature · 1 line
1.7.4.2
#1 lore raw

[tip:perf/urgent] x86, perf event: Turn off unstructured raw event access to offcore registers

Commit-ID:  b52c55c6a25e4515b5e075a989ff346fc251ed09
Gitweb:     http://git.kernel.org/tip/b52c55c6a25e4515b5e075a989ff346fc251ed09
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri, 22 Apr 2011 08:44:38 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Fri, 22 Apr 2011 10:02:53 +0200

x86, perf event: Turn off unstructured raw event access to offcore registers

Andi Kleen pointed out that the Intel offcore support patches were merged without user-space tool support to the functionality:

 |
 | The offcore_msr perf kernel code was merged into 2.6.39-rc*, but the
 | user space bits were not. This made it impossible to set the extra mask
 | and actually do the OFFCORE profiling
 |

Andi submitted a preliminary patch for user-space support, as an extension to perf's raw event syntax:

 |
 | Some raw events -- like the Intel OFFCORE events -- support additional
 | parameters. These can be appended after a ':'.
 |
 | For example on a multi socket Intel Nehalem:
 |
 |    perf stat -e r1b7:20ff -a sleep 1
 |
 | Profile the OFFCORE_RESPONSE.ANY_REQUEST with event mask REMOTE_DRAM_0
 | that measures any access to DRAM on another socket.
 |

But this kind of usability is absolutely unacceptable - users should not be expected to type in magic, CPU and model specific incantations to get access to useful hardware functionality.

The proper solution is to expose useful offcore functionality via generalized events - that way users do not have to care which specific CPU model they are using, they can use the conceptual event and not some model specific quirky hexa number.

We already have such generalization in place for CPU cache events, and it's all very extensible.

"Offcore" events measure general DRAM access patters along various parameters. They are particularly useful in NUMA systems.

We want to support them via generalized DRAM events: either as the fourth level of cache (after the last-level cache), or as a separate generalization category.

That way user-space support would be very obvious, memory access profiling could be done via self-explanatory commands like:

perf record -e dram ./myapp
perf record -e dram-remote ./myapp

... to measure DRAM accesses or more expensive cross-node NUMA DRAM accesses.

These generalized events would work on all CPUs and architectures that have comparable PMU features.

( Note, these are just examples: actual implementation could have more
sophistication and more parameter - as long as they center around similarly simple usecases. )

Now we do not want to revert *all* of the current offcore bits, as they are still somewhat useful for generic last-level-cache events, implemented in this commit:

e994d7d23a0b: perf: Fix LLC-* events on Intel Nehalem/Westmere

But we definitely do not yet want to expose the unstructured raw events to user-space, until better generalization and usability is implemented for these hardware event features.

( Note: after generalization has been implemented raw offcore events can be
supported as well: there can always be an odd event that is marginally useful but not useful enough to generalize. DRAM profiling is definitely *not* such a category so generalization must be done first. )

Furthermore, PERF_TYPE_RAW access to these registers was not intended to go upstream without proper support - it was a side-effect of the above e994d7d23a0b commit, not mentioned in the changelog.

As v2.6.39 is nearing release we go for the simplest approach: disable the PERF_TYPE_RAW offcore hack for now, before it escapes into a released kernel and becomes an ABI.

Once proper structure is implemented for these hardware events and users are offered usable solutions we can revisit this issue.

---
 arch/x86/kernel/cpu/perf_event.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)
arch/x86/kernel/cpu/perf_event.c +5 -1
index eed3673a..632e5dc 100644
@@ -586,8 +586,12 @@ static int x86_setup_perfctr(struct perf_event *event)
 			return -EOPNOTSUPP;
 	}
 
+	/*
+	 * Do not allow config1 (extended registers) to propagate,
+	 * there's no sane user-space generalization yet:
+	 */
 	if (attr->type == PERF_TYPE_RAW)
-		return x86_pmu_extra_regs(event->attr.config, event);
+		return 0;
 
 	if (attr->type == PERF_TYPE_HW_CACHE)
 		return set_ext_hw_attr(hwc, event);