[PATCH 0/4] perf tools: Add support for IBS

[PATCH 0/4] perf tools: Add support for IBS

[Robert Richter]

This patch series adds perf tool support for IBS. It is related to the
kernel patches I sent out recently.

IBS is implemented using dynamic pmu allocation. Thus, esp. event
selection and sample encoding requires handling of dynamically
generated pmu identifiers that can be queried in sysfs. For ibs there
exists 2 pmus:

 /sys/bus/event_source/devices/ibs_op/type
 /sys/bus/event_source/devices/ibs_fetch/type

Lin's patch implements a new syntax to specify events of dynamically
allocated pmus. This can be used to specify ibs events for perf
record, etc., for example:

 perf record -e ibs_op:r0 -c 100000 -R -a <command>
 perf record -e ibs_fetch:r0 -c 100000 -R -a <command>

With patch #2 dynamically generated pmu mappings are added to the
perf.data header. This information is required to decode samples and
to find the originating pmu it is comming from. Since the information
in sysfs may change we need to store it in the header.

A generic perl handler is added to process IBS events with perf
script. There was only support for tracepoints. The following perf
script commands can be used to collect and display IBS samples:

 perf script ibs ibs_op <command>
 perf script ibs ibs_fetch <command>
 perf script record ibs ibs_op -c 500000 <command>
 perf script report ibs
 perf script record ibs ibs_op -c 500000 <command> | perf script report ibs

-Robert


Lin Ming (1):
  perf tool: Parse general/raw events from sysfs

Robert Richter (3):
  perf tools: Add pmu mappings to header information
  perf script: Add generic perl handler to process events
  perf script: Add script to collect and display IBS samples

 tools/perf/scripts/perl/bin/ibs-record             |   23 +++++
 tools/perf/scripts/perl/bin/ibs-report             |    6 +
 tools/perf/scripts/perl/ibs.pl                     |   47 +++++++++
 tools/perf/util/header.c                           |   99 ++++++++++++++++++++
 tools/perf/util/header.h                           |    1 +
 tools/perf/util/parse-events.c                     |   84 ++++++++++++++++-
 .../perf/util/scripting-engines/trace-event-perl.c |   73 +++++++++++++-
 7 files changed, 325 insertions(+), 8 deletions(-)
 create mode 100644 tools/perf/scripts/perl/bin/ibs-record
 create mode 100644 tools/perf/scripts/perl/bin/ibs-report
 create mode 100644 tools/perf/scripts/perl/ibs.pl

-- 
1.7.7

[PATCH 1/4] perf tool: Parse general/raw events from sysfs

[Robert Richter]

From: Lin Ming <ming.m.lin@intel.com>

PMU can export general events to sysfs, for example,

/sys/bus/event_source/devices/uncore/events
└── cycle

Then specify the event as <pmu>:<event>,

$ sudo perf stat -a -C 0 -e uncore:cycle
^C
 Performance counter stats for 'CPU 0':

        56,547,314 uncore:cycle

Raw event can be specified as <pmu>:rXXXX

$ sudo perf stat -a -C 0 -e uncore:r0101
^C
 Performance counter stats for 'CPU 0':

             8,504 uncore:r0101

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
 tools/perf/util/parse-events.c |   84 +++++++++++++++++++++++++++++++++++++++-
 1 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 586ab3f..4ce9404 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -685,7 +685,7 @@ parse_symbolic_event(const char **strp, struct perf_event_attr *attr)
 }
 
 static enum event_result
-parse_raw_event(const char **strp, struct perf_event_attr *attr)
+parse_raw_config(const char **strp, struct perf_event_attr *attr)
 {
 	const char *str = *strp;
 	u64 config;
@@ -700,7 +700,6 @@ parse_raw_event(const char **strp, struct perf_event_attr *attr)
 			return EVT_FAILED;
 
 		*strp = end;
-		attr->type = PERF_TYPE_RAW;
 		attr->config = config;
 		return EVT_HANDLED;
 	}
@@ -708,6 +707,83 @@ parse_raw_event(const char **strp, struct perf_event_attr *attr)
 }
 
 static enum event_result
+parse_raw_event(const char **strp, struct perf_event_attr *attr)
+{
+	if (parse_raw_config(strp, attr) != EVT_HANDLED)
+		return EVT_FAILED;
+
+	attr->type = PERF_TYPE_RAW;
+	return EVT_HANDLED;
+}
+
+#define EVENT_SOURCE_DIR "/sys/bus/event_source/devices"
+
+static u64 read_sysfs_entry(const char *path)
+{
+	char buf[19];
+	int fd;
+
+	fd = open(path, O_RDONLY);
+	if (fd < 0)
+		return -1;
+
+	if (read(fd, buf, sizeof(buf)) < 0) {
+		close(fd);
+		return -1;
+	}
+
+	close(fd);
+	return atoll(buf);
+}
+
+static u64 get_pmu_type(const char *pmu_name)
+{
+	char evt_path[MAXPATHLEN];
+
+	snprintf(evt_path, MAXPATHLEN, "%s/%s/type", EVENT_SOURCE_DIR,
+		 pmu_name);
+
+	return read_sysfs_entry(evt_path);
+}
+
+static u64 get_pmu_event_config(const char *pmu_name, const char *evt_name)
+{
+	char evt_path[MAXPATHLEN];
+
+	snprintf(evt_path, MAXPATHLEN, "%s/%s/events/%s", EVENT_SOURCE_DIR,
+		 pmu_name, evt_name);
+
+	return read_sysfs_entry(evt_path);
+}
+
+static enum event_result
+parse_sysfs_event(const char **strp, struct perf_event_attr *attr)
+{
+	char *pmu_name, *evt_name;
+	u64 type, config;
+
+	pmu_name = strchr(*strp, ':');
+	if (!pmu_name)
+		return EVT_FAILED;
+	pmu_name = strndup(*strp, pmu_name - *strp);
+	type = get_pmu_type(pmu_name);
+	if ((int)type < 0)
+		return EVT_FAILED;
+	attr->type = type;
+
+	evt_name = strchr(*strp, ':') + 1;
+	config = get_pmu_event_config(pmu_name, evt_name);
+	*strp += strlen(pmu_name) + 1; /* + 1 for the ':' */
+
+	if ((int)config < 0)
+		return parse_raw_config(strp, attr);
+
+	attr->config = config;
+	*strp += strlen(evt_name);
+	return EVT_HANDLED;
+}
+
+static enum event_result
 parse_numeric_event(const char **strp, struct perf_event_attr *attr)
 {
 	const char *str = *strp;
@@ -788,6 +864,10 @@ parse_event_symbols(struct perf_evlist *evlist, const char **str,
 {
 	enum event_result ret;
 
+	ret = parse_sysfs_event(str, attr);
+	if (ret != EVT_FAILED)
+		goto modifier;
+
 	ret = parse_tracepoint_event(evlist, str, attr);
 	if (ret != EVT_FAILED)
 		goto modifier;
-- 
1.7.7

Re: [PATCH 1/4] perf tool: Parse general/raw events from sysfs

[Robert Richter]

On 15.12.11 18:23:41, Robert Richter wrote:
> From: Lin Ming <ming.m.lin@intel.com>
> 
> PMU can export general events to sysfs, for example,
> 
> /sys/bus/event_source/devices/uncore/events
> └── cycle
> 
> Then specify the event as <pmu>:<event>,
> 
> $ sudo perf stat -a -C 0 -e uncore:cycle
> ^C
>  Performance counter stats for 'CPU 0':
> 
>         56,547,314 uncore:cycle
> 
> Raw event can be specified as <pmu>:rXXXX
> 
> $ sudo perf stat -a -C 0 -e uncore:r0101
> ^C
>  Performance counter stats for 'CPU 0':
> 
>              8,504 uncore:r0101
> 
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>

Forgot this:

Signed-off-by: Robert Richter <robert.richter@amd.com>

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 1/4] perf tool: Parse general/raw events from sysfs

[Stephane Eranian]

Robert,

I must be missing somerthing but which patch adds:

/sys/bus/event_source/devices/ibs_op/events/r0

It seems the modified perf tool insists on getting the event encoding from sysfs
yet I don't see that in your patchset.

On Thu, Dec 15, 2011 at 5:23 PM, Robert Richter <robert.richter@amd.com> wrote:
> From: Lin Ming <ming.m.lin@intel.com>
>
> PMU can export general events to sysfs, for example,
>
> /sys/bus/event_source/devices/uncore/events
> └── cycle
>
> Then specify the event as <pmu>:<event>,
>
> $ sudo perf stat -a -C 0 -e uncore:cycle
> ^C
>  Performance counter stats for 'CPU 0':
>
>        56,547,314 uncore:cycle
>
> Raw event can be specified as <pmu>:rXXXX
>
> $ sudo perf stat -a -C 0 -e uncore:r0101
> ^C
>  Performance counter stats for 'CPU 0':
>
>             8,504 uncore:r0101
>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
>  tools/perf/util/parse-events.c |   84 +++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index 586ab3f..4ce9404 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -685,7 +685,7 @@ parse_symbolic_event(const char **strp, struct perf_event_attr *attr)
>  }
>
>  static enum event_result
> -parse_raw_event(const char **strp, struct perf_event_attr *attr)
> +parse_raw_config(const char **strp, struct perf_event_attr *attr)
>  {
>        const char *str = *strp;
>        u64 config;
> @@ -700,7 +700,6 @@ parse_raw_event(const char **strp, struct perf_event_attr *attr)
>                        return EVT_FAILED;
>
>                *strp = end;
> -               attr->type = PERF_TYPE_RAW;
>                attr->config = config;
>                return EVT_HANDLED;
>        }
> @@ -708,6 +707,83 @@ parse_raw_event(const char **strp, struct perf_event_attr *attr)
>  }
>
>  static enum event_result
> +parse_raw_event(const char **strp, struct perf_event_attr *attr)
> +{
> +       if (parse_raw_config(strp, attr) != EVT_HANDLED)
> +               return EVT_FAILED;
> +
> +       attr->type = PERF_TYPE_RAW;
> +       return EVT_HANDLED;
> +}
> +
> +#define EVENT_SOURCE_DIR "/sys/bus/event_source/devices"
> +
> +static u64 read_sysfs_entry(const char *path)
> +{
> +       char buf[19];
> +       int fd;
> +
> +       fd = open(path, O_RDONLY);
> +       if (fd < 0)
> +               return -1;
> +
> +       if (read(fd, buf, sizeof(buf)) < 0) {
> +               close(fd);
> +               return -1;
> +       }
> +
> +       close(fd);
> +       return atoll(buf);
> +}
> +
> +static u64 get_pmu_type(const char *pmu_name)
> +{
> +       char evt_path[MAXPATHLEN];
> +
> +       snprintf(evt_path, MAXPATHLEN, "%s/%s/type", EVENT_SOURCE_DIR,
> +                pmu_name);
> +
> +       return read_sysfs_entry(evt_path);
> +}
> +
> +static u64 get_pmu_event_config(const char *pmu_name, const char *evt_name)
> +{
> +       char evt_path[MAXPATHLEN];
> +
> +       snprintf(evt_path, MAXPATHLEN, "%s/%s/events/%s", EVENT_SOURCE_DIR,
> +                pmu_name, evt_name);
> +
> +       return read_sysfs_entry(evt_path);
> +}
> +
> +static enum event_result
> +parse_sysfs_event(const char **strp, struct perf_event_attr *attr)
> +{
> +       char *pmu_name, *evt_name;
> +       u64 type, config;
> +
> +       pmu_name = strchr(*strp, ':');
> +       if (!pmu_name)
> +               return EVT_FAILED;
> +       pmu_name = strndup(*strp, pmu_name - *strp);
> +       type = get_pmu_type(pmu_name);
> +       if ((int)type < 0)
> +               return EVT_FAILED;
> +       attr->type = type;
> +
> +       evt_name = strchr(*strp, ':') + 1;
> +       config = get_pmu_event_config(pmu_name, evt_name);
> +       *strp += strlen(pmu_name) + 1; /* + 1 for the ':' */
> +
> +       if ((int)config < 0)
> +               return parse_raw_config(strp, attr);
> +
> +       attr->config = config;
> +       *strp += strlen(evt_name);
> +       return EVT_HANDLED;
> +}
> +
> +static enum event_result
>  parse_numeric_event(const char **strp, struct perf_event_attr *attr)
>  {
>        const char *str = *strp;
> @@ -788,6 +864,10 @@ parse_event_symbols(struct perf_evlist *evlist, const char **str,
>  {
>        enum event_result ret;
>
> +       ret = parse_sysfs_event(str, attr);
> +       if (ret != EVT_FAILED)
> +               goto modifier;
> +
>        ret = parse_tracepoint_event(evlist, str, attr);
>        if (ret != EVT_FAILED)
>                goto modifier;
> --
> 1.7.7
>
>

[PATCH 2/4] perf tools: Add pmu mappings to header information

[Robert Richter]

With dynamic pmu allocation there are also dynamically assigned pmu
ids. These ids are used in event->attr.type to describe the pmu to be
used for that event. The information is available in sysfs, e.g:

 /sys/bus/event_source/devices/breakpoint/type: 5
 /sys/bus/event_source/devices/cpu/type: 4
 /sys/bus/event_source/devices/ibs_fetch/type: 6
 /sys/bus/event_source/devices/ibs_op/type: 7
 /sys/bus/event_source/devices/software/type: 1
 /sys/bus/event_source/devices/tracepoint/type: 2

These mappings are needed to know which samples belong to which pmu.
If a pmu is added dynamically like for ibs_fetch or ibs_op the type
value may vary.

Now, when decoding samples from perf.data this information in sysfs
might be no longer available or may have changed. We need to store it
in perf.data. Using the header for this. The header information
created with perf report would contain an additional section looking
like this:

 # pmu mappings: ibs_op = 7, ibs_fetch = 6, cpu = 4, breakpoint = 5, tracepoint = 2, software = 1

Signed-off-by: Robert Richter <robert.richter@amd.com>
---
 tools/perf/util/header.c |   99 ++++++++++++++++++++++++++++++++++++++++++++++
 tools/perf/util/header.h |    1 +
 2 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 1e38c10..52dd7b4 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -988,6 +988,73 @@ done:
 	return ret;
 }
 
+#define EVENT_SOURCE_DEVICE_PATH "/sys/bus/event_source/devices/"
+
+/*
+ * File format:
+ *
+ * struct pmu_mappings {
+ *	u32	pmu_num;
+ *	struct pmu_map {
+ *		u32	type;
+ *		char	name[];
+ *	}[pmu_num];
+ * };
+ */
+
+static int write_pmu_mappings(int fd, struct perf_header *h __used,
+			      struct perf_evlist *evlist __used)
+{
+	char path[MAXPATHLEN];
+	DIR *dir;
+	struct dirent *dent;
+	FILE *fp;
+	char *line = NULL;
+	off_t offset = lseek(fd, 0, SEEK_CUR);
+	size_t ignore;
+	u32 pmu_num = 0;
+	u32 type;
+
+	dir = opendir(EVENT_SOURCE_DEVICE_PATH);
+	if (!dir)
+		return -1;
+
+	/* write real pmu_num later */
+	do_write(fd, &pmu_num, sizeof(pmu_num));
+
+	while ((dent = readdir(dir))) {
+		if (!strcmp(dent->d_name, ".") || !strcmp(dent->d_name, ".."))
+			continue;
+		snprintf(path, sizeof(path), "%s%s/type",
+			 EVENT_SOURCE_DEVICE_PATH, dent->d_name);
+		fp = fopen(path, "r");
+		if (!fp)
+			continue;
+		if (getline(&line, &ignore, fp) < 0) {
+			fclose(fp);
+			continue;
+		}
+		fclose(fp);
+		type = atoi(line);
+		if (!type)
+			continue;
+		pmu_num++;
+		do_write(fd, &type, sizeof(type));
+		do_write_string(fd, dent->d_name);
+	}
+
+	free(line);
+	closedir(dir);
+
+	if (pwrite(fd, &pmu_num, sizeof(pmu_num), offset) != sizeof(pmu_num)) {
+		/* discard all */
+		lseek(fd, offset, SEEK_SET);
+		return -1;
+	}
+
+	return 0;
+}
+
 /*
  * default get_cpuid(): nothing gets recorded
  * actual implementation must be in arch/$(ARCH)/util/header.c
@@ -1305,6 +1372,37 @@ static void print_cpuid(struct perf_header *ph, int fd, FILE *fp)
 	free(str);
 }
 
+static void print_pmu_mappings(struct perf_header *ph, int fd, FILE *fp)
+{
+	const char *delimiter = "# pmu mappings: ";
+	char *name;
+	int ret;
+	u32 pmu_num;
+	u32 type;
+
+	ret = read(fd, &pmu_num, sizeof(pmu_num));
+	if (ret != sizeof(pmu_num))
+		goto error;
+
+	if (!pmu_num)
+		goto error;
+
+	while (pmu_num--) {
+		if (read(fd, &type, sizeof(type)) != sizeof(type))
+			goto error;
+		name = do_read_string(fd, ph);
+		fprintf(fp, "%s%s = %" PRIu32, delimiter, name, type);
+		free(name);
+		delimiter = ", ";
+	}
+
+	fprintf(fp, "\n");
+
+	return;
+error:
+	fprintf(fp, "# pmu mappings: not available\n");
+}
+
 static int __event_process_build_id(struct build_id_event *bev,
 				    char *filename,
 				    struct perf_session *session)
@@ -1509,6 +1607,7 @@ static const struct feature_ops feat_ops[HEADER_LAST_FEATURE] = {
 	FEAT_OPA(HEADER_CMDLINE,	cmdline),
 	FEAT_OPF(HEADER_CPU_TOPOLOGY,	cpu_topology),
 	FEAT_OPF(HEADER_NUMA_TOPOLOGY,	numa_topology),
+	FEAT_OPA(HEADER_PMU_MAPPINGS,	pmu_mappings),
 };
 
 struct header_print_data {
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index e68f617..9b4d407 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -27,6 +27,7 @@ enum {
 	HEADER_EVENT_DESC,
 	HEADER_CPU_TOPOLOGY,
 	HEADER_NUMA_TOPOLOGY,
+	HEADER_PMU_MAPPINGS,
 
 	HEADER_LAST_FEATURE,
 	HEADER_FEAT_BITS	= 256,
-- 
1.7.7

[PATCH 3/4] perf script: Add generic perl handler to process events

[Robert Richter]

The current perf scripting facility only supports tracepoints. This
patch implements a generic perl handler to support other events than
tracepoints too.

This patch introduces a function process_event() that is called by
perf for each sample. The function is called with byte streams as
arguments containing information about the event, its attributes, the
sample and raw data. Perl's unpack() function can easily be used for
byte decoding. The following is the default implementation for
process_event() that can also be generated with perf script:

 # Packed byte string args of process_event():
 #
 # $event:       union perf_event        util/event.h
 # $attr:        struct perf_event_attr  linux/perf_event.h
 # $sample:      struct perf_sample      util/event.h
 # $raw_data:    perf_sample->raw_data   util/event.h

 sub process_event
 {
         my ($event, $attr, $sample, $raw_data) = @_;

         my @event       = unpack("LSS", $event);
         my @attr        = unpack("LLQQQQQLLQQ", $attr);
         my @sample      = unpack("QLLQQQQQLL", $sample);
         my @raw_data    = unpack("C*", $raw_data);

         use Data::Dumper;
         print Dumper \@event, \@attr, \@sample, \@raw_data;
 }

Signed-off-by: Robert Richter <robert.richter@amd.com>
---
 .../perf/util/scripting-engines/trace-event-perl.c |   73 ++++++++++++++++++--
 1 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-perl.c b/tools/perf/util/scripting-engines/trace-event-perl.c
index a82ce43..e30749e 100644
--- a/tools/perf/util/scripting-engines/trace-event-perl.c
+++ b/tools/perf/util/scripting-engines/trace-event-perl.c
@@ -30,6 +30,7 @@
 #include "../thread.h"
 #include "../event.h"
 #include "../trace-event.h"
+#include "../evsel.h"
 
 #include <EXTERN.h>
 #include <perl.h>
@@ -247,11 +248,11 @@ static inline struct event *find_cache_event(int type)
 	return event;
 }
 
-static void perl_process_event(union perf_event *pevent __unused,
-			       struct perf_sample *sample,
-			       struct perf_evsel *evsel,
-			       struct machine *machine __unused,
-			       struct thread *thread)
+static void perl_process_tracepoint(union perf_event *pevent __unused,
+				    struct perf_sample *sample,
+				    struct perf_evsel *evsel,
+				    struct machine *machine __unused,
+				    struct thread *thread)
 {
 	struct format_field *field;
 	static char handler[256];
@@ -267,6 +268,9 @@ static void perl_process_event(union perf_event *pevent __unused,
 
 	dSP;
 
+	if (evsel->attr.type != PERF_TYPE_TRACEPOINT)
+		return;
+
 	type = trace_parse_common_type(data);
 
 	event = find_cache_event(type);
@@ -334,6 +338,42 @@ static void perl_process_event(union perf_event *pevent __unused,
 	LEAVE;
 }
 
+static void perl_process_event_generic(union perf_event *pevent __unused,
+				       struct perf_sample *sample,
+				       struct perf_evsel *evsel __unused,
+				       struct machine *machine __unused,
+				       struct thread *thread __unused)
+{
+	dSP;
+
+	if (!get_cv("process_event", 0))
+		return;
+
+	ENTER;
+	SAVETMPS;
+	PUSHMARK(SP);
+	XPUSHs(sv_2mortal(newSVpvn((const char *)pevent, pevent->header.size)));
+	XPUSHs(sv_2mortal(newSVpvn((const char *)&evsel->attr, sizeof(evsel->attr))));
+	XPUSHs(sv_2mortal(newSVpvn((const char *)sample, sizeof(*sample))));
+	XPUSHs(sv_2mortal(newSVpvn((const char *)sample->raw_data, sample->raw_size)));
+	PUTBACK;
+	call_pv("process_event", G_SCALAR);
+	SPAGAIN;
+	PUTBACK;
+	FREETMPS;
+	LEAVE;
+}
+
+static void perl_process_event(union perf_event *pevent,
+			       struct perf_sample *sample,
+			       struct perf_evsel *evsel,
+			       struct machine *machine,
+			       struct thread *thread)
+{
+	perl_process_tracepoint(pevent, sample, evsel, machine, thread);
+	perl_process_event_generic(pevent, sample, evsel, machine, thread);
+}
+
 static void run_start_sub(void)
 {
 	dSP; /* access to Perl stack */
@@ -555,7 +595,28 @@ static int perl_generate_script(const char *outfile)
 	fprintf(ofp, "sub print_header\n{\n"
 		"\tmy ($event_name, $cpu, $secs, $nsecs, $pid, $comm) = @_;\n\n"
 		"\tprintf(\"%%-20s %%5u %%05u.%%09u %%8u %%-20s \",\n\t       "
-		"$event_name, $cpu, $secs, $nsecs, $pid, $comm);\n}");
+		"$event_name, $cpu, $secs, $nsecs, $pid, $comm);\n}\n");
+
+	fprintf(ofp,
+		"\n# Packed byte string args of process_event():\n"
+		"#\n"
+		"# $event:\tunion perf_event\tutil/event.h\n"
+		"# $attr:\tstruct perf_event_attr\tlinux/perf_event.h\n"
+		"# $sample:\tstruct perf_sample\tutil/event.h\n"
+		"# $raw_data:\tperf_sample->raw_data\tutil/event.h\n"
+		"\n"
+		"sub process_event\n"
+		"{\n"
+		"\tmy ($event, $attr, $sample, $raw_data) = @_;\n"
+		"\n"
+		"\tmy @event\t= unpack(\"LSS\", $event);\n"
+		"\tmy @attr\t= unpack(\"LLQQQQQLLQQ\", $attr);\n"
+		"\tmy @sample\t= unpack(\"QLLQQQQQLL\", $sample);\n"
+		"\tmy @raw_data\t= unpack(\"C*\", $raw_data);\n"
+		"\n"
+		"\tuse Data::Dumper;\n"
+		"\tprint Dumper \\@event, \\@attr, \\@sample, \\@raw_data;\n"
+		"}\n");
 
 	fclose(ofp);
 
-- 
1.7.7

[tip:perf/core] perf script: Add generic perl handler to process events

[tip-bot for Robert Richter]

Commit-ID:  37a058ea006de0cc24553637afa788594a975176
Gitweb:     http://git.kernel.org/tip/37a058ea006de0cc24553637afa788594a975176
Author:     Robert Richter <robert.richter@amd.com>
AuthorDate: Thu, 15 Dec 2011 18:23:43 +0100
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Fri, 23 Dec 2011 17:05:48 -0200

perf script: Add generic perl handler to process events

The current perf scripting facility only supports tracepoints. This
patch implements a generic perl handler to support other events than
tracepoints too.

This patch introduces a function process_event() that is called by perf
for each sample. The function is called with byte streams as arguments
containing information about the event, its attributes, the sample and
raw data. Perl's unpack() function can easily be used for byte decoding.
The following is the default implementation for process_event() that can
also be generated with perf script:

 # Packed byte string args of process_event():
 #
 # $event:       union perf_event        util/event.h
 # $attr:        struct perf_event_attr  linux/perf_event.h
 # $sample:      struct perf_sample      util/event.h
 # $raw_data:    perf_sample->raw_data   util/event.h

 sub process_event
 {
         my ($event, $attr, $sample, $raw_data) = @_;

         my @event       = unpack("LSS", $event);
         my @attr        = unpack("LLQQQQQLLQQ", $attr);
         my @sample      = unpack("QLLQQQQQLL", $sample);
         my @raw_data    = unpack("C*", $raw_data);

         use Data::Dumper;
         print Dumper \@event, \@attr, \@sample, \@raw_data;
 }

Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1323969824-9711-4-git-send-email-robert.richter@amd.com
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 .../perf/util/scripting-engines/trace-event-perl.c |   73 ++++++++++++++++++--
 1 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-perl.c b/tools/perf/util/scripting-engines/trace-event-perl.c
index a82ce43..e30749e 100644
--- a/tools/perf/util/scripting-engines/trace-event-perl.c
+++ b/tools/perf/util/scripting-engines/trace-event-perl.c
@@ -30,6 +30,7 @@
 #include "../thread.h"
 #include "../event.h"
 #include "../trace-event.h"
+#include "../evsel.h"
 
 #include <EXTERN.h>
 #include <perl.h>
@@ -247,11 +248,11 @@ static inline struct event *find_cache_event(int type)
 	return event;
 }
 
-static void perl_process_event(union perf_event *pevent __unused,
-			       struct perf_sample *sample,
-			       struct perf_evsel *evsel,
-			       struct machine *machine __unused,
-			       struct thread *thread)
+static void perl_process_tracepoint(union perf_event *pevent __unused,
+				    struct perf_sample *sample,
+				    struct perf_evsel *evsel,
+				    struct machine *machine __unused,
+				    struct thread *thread)
 {
 	struct format_field *field;
 	static char handler[256];
@@ -267,6 +268,9 @@ static void perl_process_event(union perf_event *pevent __unused,
 
 	dSP;
 
+	if (evsel->attr.type != PERF_TYPE_TRACEPOINT)
+		return;
+
 	type = trace_parse_common_type(data);
 
 	event = find_cache_event(type);
@@ -334,6 +338,42 @@ static void perl_process_event(union perf_event *pevent __unused,
 	LEAVE;
 }
 
+static void perl_process_event_generic(union perf_event *pevent __unused,
+				       struct perf_sample *sample,
+				       struct perf_evsel *evsel __unused,
+				       struct machine *machine __unused,
+				       struct thread *thread __unused)
+{
+	dSP;
+
+	if (!get_cv("process_event", 0))
+		return;
+
+	ENTER;
+	SAVETMPS;
+	PUSHMARK(SP);
+	XPUSHs(sv_2mortal(newSVpvn((const char *)pevent, pevent->header.size)));
+	XPUSHs(sv_2mortal(newSVpvn((const char *)&evsel->attr, sizeof(evsel->attr))));
+	XPUSHs(sv_2mortal(newSVpvn((const char *)sample, sizeof(*sample))));
+	XPUSHs(sv_2mortal(newSVpvn((const char *)sample->raw_data, sample->raw_size)));
+	PUTBACK;
+	call_pv("process_event", G_SCALAR);
+	SPAGAIN;
+	PUTBACK;
+	FREETMPS;
+	LEAVE;
+}
+
+static void perl_process_event(union perf_event *pevent,
+			       struct perf_sample *sample,
+			       struct perf_evsel *evsel,
+			       struct machine *machine,
+			       struct thread *thread)
+{
+	perl_process_tracepoint(pevent, sample, evsel, machine, thread);
+	perl_process_event_generic(pevent, sample, evsel, machine, thread);
+}
+
 static void run_start_sub(void)
 {
 	dSP; /* access to Perl stack */
@@ -555,7 +595,28 @@ static int perl_generate_script(const char *outfile)
 	fprintf(ofp, "sub print_header\n{\n"
 		"\tmy ($event_name, $cpu, $secs, $nsecs, $pid, $comm) = @_;\n\n"
 		"\tprintf(\"%%-20s %%5u %%05u.%%09u %%8u %%-20s \",\n\t       "
-		"$event_name, $cpu, $secs, $nsecs, $pid, $comm);\n}");
+		"$event_name, $cpu, $secs, $nsecs, $pid, $comm);\n}\n");
+
+	fprintf(ofp,
+		"\n# Packed byte string args of process_event():\n"
+		"#\n"
+		"# $event:\tunion perf_event\tutil/event.h\n"
+		"# $attr:\tstruct perf_event_attr\tlinux/perf_event.h\n"
+		"# $sample:\tstruct perf_sample\tutil/event.h\n"
+		"# $raw_data:\tperf_sample->raw_data\tutil/event.h\n"
+		"\n"
+		"sub process_event\n"
+		"{\n"
+		"\tmy ($event, $attr, $sample, $raw_data) = @_;\n"
+		"\n"
+		"\tmy @event\t= unpack(\"LSS\", $event);\n"
+		"\tmy @attr\t= unpack(\"LLQQQQQLLQQ\", $attr);\n"
+		"\tmy @sample\t= unpack(\"QLLQQQQQLL\", $sample);\n"
+		"\tmy @raw_data\t= unpack(\"C*\", $raw_data);\n"
+		"\n"
+		"\tuse Data::Dumper;\n"
+		"\tprint Dumper \\@event, \\@attr, \\@sample, \\@raw_data;\n"
+		"}\n");
 
 	fclose(ofp);
 

[PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

This patch adds a script to collect and display IBS samples.
There are the following options:

 perf script ibs [ibs_op|ibs_fetch] [-c period] <command>

Examples for usage:

 perf script ibs ibs_op <command>
 perf script ibs ibs_fetch <command>
 perf script record ibs ibs_op -c 500000 <command>
 perf script report ibs
 perf script record ibs ibs_op -c 500000 <command> | perf script report ibs

Signed-off-by: Robert Richter <robert.richter@amd.com>
---
 tools/perf/scripts/perl/bin/ibs-record |   23 +++++++++++++++
 tools/perf/scripts/perl/bin/ibs-report |    6 ++++
 tools/perf/scripts/perl/ibs.pl         |   47 ++++++++++++++++++++++++++++++++
 3 files changed, 76 insertions(+), 0 deletions(-)
 create mode 100644 tools/perf/scripts/perl/bin/ibs-record
 create mode 100644 tools/perf/scripts/perl/bin/ibs-report
 create mode 100644 tools/perf/scripts/perl/ibs.pl

diff --git a/tools/perf/scripts/perl/bin/ibs-record b/tools/perf/scripts/perl/bin/ibs-record
new file mode 100644
index 0000000..dc5f4d2
--- /dev/null
+++ b/tools/perf/scripts/perl/bin/ibs-record
@@ -0,0 +1,23 @@
+#! /bin/bash
+
+while [ "${1+defined}" ]; do
+    case $1 in
+	ibs_op|ibs_fetch)
+	    EVENT=$1
+	    shift
+	    break
+	    ;;
+	-*)
+	    REC_OPT+=($1)
+	    shift
+	    ;;
+	*)
+	    echo $0 "$@" >&2
+	    echo "Invalid option: $1" >&2
+	    echo "perf script ibs [ibs_op|ibs_fetch] [-c <period>]" >&2
+	    exit 1
+	    ;;
+    esac
+done
+
+perf record -e ${EVENT:-ibs_op}:r0 -c 100000 -R -a "${REC_OPT[@]}" "$@"
diff --git a/tools/perf/scripts/perl/bin/ibs-report b/tools/perf/scripts/perl/bin/ibs-report
new file mode 100644
index 0000000..f44e69d
--- /dev/null
+++ b/tools/perf/scripts/perl/bin/ibs-report
@@ -0,0 +1,6 @@
+#! /bin/bash
+
+# description: collect and display AMD IBS samples
+# args: [ibs_op|ibs_fetch] [-c period]
+
+perf script -s "$PERF_EXEC_PATH"/scripts/perl/ibs.pl "$@"
diff --git a/tools/perf/scripts/perl/ibs.pl b/tools/perf/scripts/perl/ibs.pl
new file mode 100644
index 0000000..caee32f
--- /dev/null
+++ b/tools/perf/scripts/perl/ibs.pl
@@ -0,0 +1,47 @@
+#
+# ibs.pl - perf script for AMD Instruction Based Sampling
+#
+# Copyright (C) 2011 Advanced Micro Devices, Inc., Robert Richter
+#
+# For licencing details see kernel-base/COPYING
+#
+# description: collect and display AMD IBS samples
+# args: [ibs_op|ibs_fetch] [-c period]
+#
+# examples:
+#
+#  perf script ibs ibs_op <command>
+#  perf script ibs ibs_fetch <command>
+#  perf script record ibs ibs_op -c 500000 <command>
+#  perf script report ibs
+#  perf script record ibs ibs_op -c 500000 <command> | perf script report ibs
+#
+
+# Packed byte string args of process_event():
+#
+# $event:	union perf_event	util/event.h
+# $attr:	struct perf_event_attr	linux/perf_event.h
+# $sample:	struct perf_sample	util/event.h
+# $raw_data:	perf_sample->raw_data	util/event.h
+
+sub process_event
+{
+	my ($event, $attr, $sample, $raw_data) = @_;
+
+	my ($type)		= (unpack("LSS", $event))[0];
+	my ($sample_type)	= (unpack("LLQQQQQLLQQ", $attr))[4];
+	my ($cpu, $raw_size)	= (unpack("QLLQQQQQLL", $sample))[8, 9];
+	my ($caps, @ibs_data)	= unpack("LQ*", $raw_data);
+
+	return if (!$raw_size);		# no raw data
+
+	if (scalar(@ibs_data) ==  3) {
+	        printf("IBS_FETCH sample on cpu%d\tIBS0: 0x%016x IBS1: 0x%016x IBS2:0x%016x\n",
+		       $cpu, @ibs_data);
+	} else {
+	        printf("IBS_OP sample on cpu%d\t" .
+		       "\t IBS0: 0x%016x IBS1: 0x%016x IBS2: 0x%016x\n" .
+		       "\tIBS3: 0x%016x IBS4: 0x%016x IBS5: 0x%016x IBS6: 0x%016x\n",
+		       cpu, @ibs_data);
+	}
+}
-- 
1.7.7

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[David Ahern]

On 12/15/2011 10:23 AM, Robert Richter wrote:
> This patch adds a script to collect and display IBS samples.
> There are the following options:
> 
>  perf script ibs [ibs_op|ibs_fetch] [-c period] <command>
> 
> Examples for usage:
> 
>  perf script ibs ibs_op <command>
>  perf script ibs ibs_fetch <command>
>  perf script record ibs ibs_op -c 500000 <command>
>  perf script report ibs
>  perf script record ibs ibs_op -c 500000 <command> | perf script report ibs
> 
> Signed-off-by: Robert Richter <robert.richter@amd.com>
> ---
>  tools/perf/scripts/perl/bin/ibs-record |   23 +++++++++++++++
>  tools/perf/scripts/perl/bin/ibs-report |    6 ++++
>  tools/perf/scripts/perl/ibs.pl         |   47 ++++++++++++++++++++++++++++++++
>  3 files changed, 76 insertions(+), 0 deletions(-)
>  create mode 100644 tools/perf/scripts/perl/bin/ibs-record
>  create mode 100644 tools/perf/scripts/perl/bin/ibs-report
>  create mode 100644 tools/perf/scripts/perl/ibs.pl
> 
> diff --git a/tools/perf/scripts/perl/bin/ibs-record b/tools/perf/scripts/perl/bin/ibs-record
> new file mode 100644
> index 0000000..dc5f4d2
> --- /dev/null
> +++ b/tools/perf/scripts/perl/bin/ibs-record
> @@ -0,0 +1,23 @@
> +#! /bin/bash
> +
> +while [ "${1+defined}" ]; do
> +    case $1 in
> +	ibs_op|ibs_fetch)
> +	    EVENT=$1
> +	    shift
> +	    break
> +	    ;;
> +	-*)
> +	    REC_OPT+=($1)
> +	    shift
> +	    ;;
> +	*)
> +	    echo $0 "$@" >&2
> +	    echo "Invalid option: $1" >&2
> +	    echo "perf script ibs [ibs_op|ibs_fetch] [-c <period>]" >&2
> +	    exit 1
> +	    ;;
> +    esac
> +done
> +
> +perf record -e ${EVENT:-ibs_op}:r0 -c 100000 -R -a "${REC_OPT[@]}" "$@"
> diff --git a/tools/perf/scripts/perl/bin/ibs-report b/tools/perf/scripts/perl/bin/ibs-report
> new file mode 100644
> index 0000000..f44e69d
> --- /dev/null
> +++ b/tools/perf/scripts/perl/bin/ibs-report
> @@ -0,0 +1,6 @@
> +#! /bin/bash
> +
> +# description: collect and display AMD IBS samples
> +# args: [ibs_op|ibs_fetch] [-c period]
> +
> +perf script -s "$PERF_EXEC_PATH"/scripts/perl/ibs.pl "$@"
> diff --git a/tools/perf/scripts/perl/ibs.pl b/tools/perf/scripts/perl/ibs.pl
> new file mode 100644
> index 0000000..caee32f
> --- /dev/null
> +++ b/tools/perf/scripts/perl/ibs.pl
> @@ -0,0 +1,47 @@
> +#
> +# ibs.pl - perf script for AMD Instruction Based Sampling
> +#
> +# Copyright (C) 2011 Advanced Micro Devices, Inc., Robert Richter
> +#
> +# For licencing details see kernel-base/COPYING
> +#
> +# description: collect and display AMD IBS samples
> +# args: [ibs_op|ibs_fetch] [-c period]
> +#
> +# examples:
> +#
> +#  perf script ibs ibs_op <command>
> +#  perf script ibs ibs_fetch <command>
> +#  perf script record ibs ibs_op -c 500000 <command>
> +#  perf script report ibs
> +#  perf script record ibs ibs_op -c 500000 <command> | perf script report ibs
> +#
> +
> +# Packed byte string args of process_event():
> +#
> +# $event:	union perf_event	util/event.h
> +# $attr:	struct perf_event_attr	linux/perf_event.h
> +# $sample:	struct perf_sample	util/event.h
> +# $raw_data:	perf_sample->raw_data	util/event.h
> +
> +sub process_event
> +{
> +	my ($event, $attr, $sample, $raw_data) = @_;
> +
> +	my ($type)		= (unpack("LSS", $event))[0];
> +	my ($sample_type)	= (unpack("LLQQQQQLLQQ", $attr))[4];
> +	my ($cpu, $raw_size)	= (unpack("QLLQQQQQLL", $sample))[8, 9];
> +	my ($caps, @ibs_data)	= unpack("LQ*", $raw_data);
> +
> +	return if (!$raw_size);		# no raw data
> +
> +	if (scalar(@ibs_data) ==  3) {
> +	        printf("IBS_FETCH sample on cpu%d\tIBS0: 0x%016x IBS1: 0x%016x IBS2:0x%016x\n",
> +		       $cpu, @ibs_data);
> +	} else {
> +	        printf("IBS_OP sample on cpu%d\t" .
> +		       "\t IBS0: 0x%016x IBS1: 0x%016x IBS2: 0x%016x\n" .
> +		       "\tIBS3: 0x%016x IBS4: 0x%016x IBS5: 0x%016x IBS6: 0x%016x\n",
> +		       cpu, @ibs_data);
> +	}
> +}

Doesn't seem like you are verifying that the tracepoints fed to this
script are actually ibs related. For example, if a user points to the
wrong perf.data which has raw data in it this script would happily parse
and display numbers.

Also, why a perl script versus the builtin dumping capability of
perf-script? e.g., add ibs to the fields and while processing the event
verify that the tracepoint is ibs related.

David

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

On 15.12.11 12:19:03, David Ahern wrote:

> > +sub process_event
> > +{
> > +	my ($event, $attr, $sample, $raw_data) = @_;
> > +
> > +	my ($type)		= (unpack("LSS", $event))[0];
> > +	my ($sample_type)	= (unpack("LLQQQQQLLQQ", $attr))[4];
> > +	my ($cpu, $raw_size)	= (unpack("QLLQQQQQLL", $sample))[8, 9];
> > +	my ($caps, @ibs_data)	= unpack("LQ*", $raw_data);
> > +
> > +	return if (!$raw_size);		# no raw data
> > +
> > +	if (scalar(@ibs_data) ==  3) {
> > +	        printf("IBS_FETCH sample on cpu%d\tIBS0: 0x%016x IBS1: 0x%016x IBS2:0x%016x\n",
> > +		       $cpu, @ibs_data);
> > +	} else {
> > +	        printf("IBS_OP sample on cpu%d\t" .
> > +		       "\t IBS0: 0x%016x IBS1: 0x%016x IBS2: 0x%016x\n" .
> > +		       "\tIBS3: 0x%016x IBS4: 0x%016x IBS5: 0x%016x IBS6: 0x%016x\n",
> > +		       cpu, @ibs_data);
> > +	}
> > +}
> 
> Doesn't seem like you are verifying that the tracepoints fed to this
> script are actually ibs related. For example, if a user points to the
> wrong perf.data which has raw data in it this script would happily parse
> and display numbers.

For 'perf script ibs' and 'perf script record ibs' this does not
matter as the builtin perf record wrapper is used that always creates
ibs data. For 'perf script report ibs' the perf.data file is not
checked for valid ibs samples. In case you point to a wrong file your
report will be wrong too. I don't think this is an issue for this
initial version. The pmu mapping is already in the header so
implementing a check is generally possible.

> Also, why a perl script versus the builtin dumping capability of
> perf-script? e.g., add ibs to the fields and while processing the event
> verify that the tracepoint is ibs related.

IBS samples are not tracepoints but some special kind of hardware
event. It would be hard to reuse the tracing framework for this. Also,
the parser above is intended to be a reference implementation of how
to generate and decode ibs samples. It should be the basis for
customized scripts to extract information from ibs data.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Ingo Molnar]

* Robert Richter <robert.richter@amd.com> wrote:

> This patch adds a script to collect and display IBS samples.
> There are the following options:
> 
>  perf script ibs [ibs_op|ibs_fetch] [-c period] <command>
> 
> Examples for usage:
> 
>  perf script ibs ibs_op <command>
>  perf script ibs ibs_fetch <command>
>  perf script record ibs ibs_op -c 500000 <command>
>  perf script report ibs
>  perf script record ibs ibs_op -c 500000 <command> | perf script report ibs

So, cannot we just integrate this into regular perf record and 
perf report?

Also, could you quote example output of "perf script report ibs"?

Thanks,

	Ingo

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

On 23.12.11 11:33:29, Ingo Molnar wrote:
> 
> * Robert Richter <robert.richter@amd.com> wrote:
> 
> > This patch adds a script to collect and display IBS samples.
> > There are the following options:
> > 
> >  perf script ibs [ibs_op|ibs_fetch] [-c period] <command>
> > 
> > Examples for usage:
> > 
> >  perf script ibs ibs_op <command>
> >  perf script ibs ibs_fetch <command>
> >  perf script record ibs ibs_op -c 500000 <command>
> >  perf script report ibs
> >  perf script record ibs ibs_op -c 500000 <command> | perf script report ibs
> 
> So, cannot we just integrate this into regular perf record and 
> perf report?

As stated in the cover letter, perf record is already there:

 perf record -e ibs_op:r0 -c 100000 -R -a <command>
 perf record -e ibs_fetch:r0 -c 100000 -R -a <command>

For perf report I was looking at parsing perf.data to output a dump
for ibs samples, but it turned out to be more useful to implement this
with perf script.

What we might do later to integrate ibs more into HW event sampling is
to redirect perfctr event requests for clk_unhalted/ops_count in
conjunction with the precise bit to ibs_op (clk_unhalted/ops). We
would then have e.g. a precise perf top. But this is clearly out of
the scope of this patch series.

> 
> Also, could you quote example output of "perf script report ibs"?

IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x0000000000444780 IBS2:0x000000041af26780
IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x00007f5efb44e3b2 IBS2:0x000000042fcff3b2
IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065273 IBS2:0x0000000001065273
IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff811a6320 IBS2:0x00000000011a6320
IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065255 IBS2:0x0000000001065255
IBS_FETCH sample on cpu7	IBS0: 0x00170004186a186a IBS1: 0x00007fbf0c687ca0 IBS2:0x000000041d345ca0
IBS_FETCH sample on cpu7	IBS0: 0x00170003186a186a IBS1: 0x000000000043bb80 IBS2:0x000000041c351b80
IBS_FETCH sample on cpu7	IBS0: 0x01370003186a186a IBS1: 0xffffffff813d5790 IBS2:0x00000000013d5790
IBS_FETCH sample on cpu7	IBS0: 0x00030001186a186a IBS1: 0xffffffff8102bd00 IBS2:0x00000000013d5d00


IBS_OP sample on cpu0            IBS0: 0x000000000006186a IBS1: 0xffffffff811a8297 IBS2: 0x0000000000490047
        IBS3: 0x0000000000000000 IBS4: 0x0000070300000000 IBS5: 0x0000000000000000 IBS6: 0x0000000000000000
IBS_OP sample on cpu4            IBS0: 0x000000000006186a IBS1: 0xffffffff8100840d IBS2: 0x0000000000040004
        IBS3: 0x0000000000000000 IBS4: 0x0000000000000000 IBS5: 0x0000000000000000 IBS6: 0x0000000000000000
IBS_OP sample on cpu0            IBS0: 0x000000000006186a IBS1: 0xffffffff811a8297 IBS2: 0x0000000000120008
        IBS3: 0x0000000000000000 IBS4: 0x0000000700060012 IBS5: 0xffff88041df23918 IBS6: 0x000000041df23918
IBS_OP sample on cpu0            IBS0: 0x000000000006186a IBS1: 0xffffffff811a8297 IBS2: 0x0000000000270002
        IBS3: 0x0000000000000000 IBS4: 0x0000064b00070092 IBS5: 0xffff88041dd93198 IBS6: 0x000000041dd93198
IBS_OP sample on cpu0            IBS0: 0x000000000006186a IBS1: 0xffffffff811a8297 IBS2: 0x00000000002d0002
        IBS3: 0x0000000000000000 IBS4: 0x0000064a00070092 IBS5: 0xffff88041e3acd18 IBS6: 0x000000041e3acd18
IBS_OP sample on cpu0            IBS0: 0x000000000006186a IBS1: 0xffffffff811a8297 IBS2: 0x0000000000160006
        IBS3: 0x0000000000000000 IBS4: 0x000008a000070092 IBS5: 0xffff88041e217990 IBS6: 0x000000041e217990
IBS_OP sample on cpu1            IBS0: 0x000000000006186a IBS1: 0xffffffff8100840d IBS2: 0x0000000000040004
        IBS3: 0x0000000000000000 IBS4: 0x0000000000000000 IBS5: 0x0000000000000000 IBS6: 0x0000000000000000
IBS_OP sample on cpu3            IBS0: 0x000000000006186a IBS1: 0xffffffff8100840d IBS2: 0x0000000000040004
        IBS3: 0x0000000000000000 IBS4: 0x0000000000000000 IBS5: 0x0000000000000000 IBS6: 0x0000000000000000
IBS_OP sample on cpu0            IBS0: 0x000000000006186a IBS1: 0xffffffff811a8297 IBS2: 0x000000000012000e
        IBS3: 0x0000000000000000 IBS4: 0x0000000300060012 IBS5: 0xffff88041effa8d0 IBS6: 0x000000041effa8d0

Esp. IBS_OP is not that good looking, but it shows how to use it and
can also be beautified and extended later. It gives the user a
direction about how to access ibs.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Ingo Molnar]

* Robert Richter <robert.richter@amd.com> wrote:

> > Also, could you quote example output of "perf script report 
> > ibs"?
> 
> IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x0000000000444780 IBS2:0x000000041af26780
> IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x00007f5efb44e3b2 IBS2:0x000000042fcff3b2
> IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065273 IBS2:0x0000000001065273
> IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff811a6320 IBS2:0x00000000011a6320
> IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065255 IBS2:0x0000000001065255
> IBS_FETCH sample on cpu7	IBS0: 0x00170004186a186a IBS1: 0x00007fbf0c687ca0 IBS2:0x000000041d345ca0
> IBS_FETCH sample on cpu7	IBS0: 0x00170003186a186a IBS1: 0x000000000043bb80 IBS2:0x000000041c351b80
> IBS_FETCH sample on cpu7	IBS0: 0x01370003186a186a IBS1: 0xffffffff813d5790 IBS2:0x00000000013d5790
> IBS_FETCH sample on cpu7	IBS0: 0x00030001186a186a IBS1: 0xffffffff8102bd00 IBS2:0x00000000013d5d00

That does not look very usable to users. So why should we merge 
this new ABI in its incomplete form with no complete usecase? 
Being usable is clearly not outside the scope of a new feature 
...

Integrating it into perf report should not be *that* hard, 
you've done most of the hard work already. But without that step 
we just don't know how complete and usable the whole thing is.

Thanks,

	Ingo

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Peter Zijlstra]

On Fri, 2011-12-23 at 14:53 +0100, Ingo Molnar wrote:
> * Robert Richter <robert.richter@amd.com> wrote:
> 
> > > Also, could you quote example output of "perf script report 
> > > ibs"?
> > 
> > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x0000000000444780 IBS2:0x000000041af26780
> > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x00007f5efb44e3b2 IBS2:0x000000042fcff3b2
> > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065273 IBS2:0x0000000001065273
> > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff811a6320 IBS2:0x00000000011a6320
> > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065255 IBS2:0x0000000001065255
> > IBS_FETCH sample on cpu7	IBS0: 0x00170004186a186a IBS1: 0x00007fbf0c687ca0 IBS2:0x000000041d345ca0
> > IBS_FETCH sample on cpu7	IBS0: 0x00170003186a186a IBS1: 0x000000000043bb80 IBS2:0x000000041c351b80
> > IBS_FETCH sample on cpu7	IBS0: 0x01370003186a186a IBS1: 0xffffffff813d5790 IBS2:0x00000000013d5790
> > IBS_FETCH sample on cpu7	IBS0: 0x00030001186a186a IBS1: 0xffffffff8102bd00 IBS2:0x00000000013d5d00
> 
> That does not look very usable to users. So why should we merge 
> this new ABI in its incomplete form with no complete usecase? 
> Being usable is clearly not outside the scope of a new feature 
> ...
> 
> Integrating it into perf report should not be *that* hard, 
> you've done most of the hard work already. But without that step 
> we just don't know how complete and usable the whole thing is.

perf annotate like output might make more sense for IBS, maybe not
decode all the information that's in there, but at least a number of the
most useful measurements for each type and present multiple columns in
front of the instructions.

Ingo, the trouble with IBS is that it doesn't measure something, its a
measure everything together like thing, so what particular part of this
massive bulk data do you use to create your histograms?

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, 2011-12-23 at 14:53 +0100, Ingo Molnar wrote:
> > * Robert Richter <robert.richter@amd.com> wrote:
> > 
> > > > Also, could you quote example output of "perf script report 
> > > > ibs"?
> > > 
> > > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x0000000000444780 IBS2:0x000000041af26780
> > > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x00007f5efb44e3b2 IBS2:0x000000042fcff3b2
> > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065273 IBS2:0x0000000001065273
> > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff811a6320 IBS2:0x00000000011a6320
> > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065255 IBS2:0x0000000001065255
> > > IBS_FETCH sample on cpu7	IBS0: 0x00170004186a186a IBS1: 0x00007fbf0c687ca0 IBS2:0x000000041d345ca0
> > > IBS_FETCH sample on cpu7	IBS0: 0x00170003186a186a IBS1: 0x000000000043bb80 IBS2:0x000000041c351b80
> > > IBS_FETCH sample on cpu7	IBS0: 0x01370003186a186a IBS1: 0xffffffff813d5790 IBS2:0x00000000013d5790
> > > IBS_FETCH sample on cpu7	IBS0: 0x00030001186a186a IBS1: 0xffffffff8102bd00 IBS2:0x00000000013d5d00
> > 
> > That does not look very usable to users. So why should we merge 
> > this new ABI in its incomplete form with no complete usecase? 
> > Being usable is clearly not outside the scope of a new feature 
> > ...
> > 
> > Integrating it into perf report should not be *that* hard, 
> > you've done most of the hard work already. But without that 
> > step we just don't know how complete and usable the whole 
> > thing is.
> 
> perf annotate like output might make more sense for IBS, maybe 
> not decode all the information that's in there, but at least a 
> number of the most useful measurements for each type and 
> present multiple columns in front of the instructions.
> 
> Ingo, the trouble with IBS is that it doesn't measure 
> something, its a measure everything together like thing, so 
> what particular part of this massive bulk data do you use to 
> create your histograms?

My point is that a useful angle to it has to be presented for it 
to be useful for upstream.

The bit that looks useful about IBS is skid-free sampling. So as 
long as the 'bulk data' contains enough information to do a 
'perf record -e instructions:p' work-alike thing it would be 
useful, right?

Sadly precise cycles sampling is not possible via IBS, right?

Thanks,

	Ingo

[*] Sidenote: i suspect the RIP+1 sampling artifact cannot be
    gotten rid of on AMD CPUs, right?

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

On 23.12.11 15:40:40, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Fri, 2011-12-23 at 14:53 +0100, Ingo Molnar wrote:
> > > * Robert Richter <robert.richter@amd.com> wrote:
> > > 
> > > > > Also, could you quote example output of "perf script report 
> > > > > ibs"?
> > > > 
> > > > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x0000000000444780 IBS2:0x000000041af26780
> > > > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x00007f5efb44e3b2 IBS2:0x000000042fcff3b2
> > > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065273 IBS2:0x0000000001065273
> > > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff811a6320 IBS2:0x00000000011a6320
> > > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065255 IBS2:0x0000000001065255
> > > > IBS_FETCH sample on cpu7	IBS0: 0x00170004186a186a IBS1: 0x00007fbf0c687ca0 IBS2:0x000000041d345ca0
> > > > IBS_FETCH sample on cpu7	IBS0: 0x00170003186a186a IBS1: 0x000000000043bb80 IBS2:0x000000041c351b80
> > > > IBS_FETCH sample on cpu7	IBS0: 0x01370003186a186a IBS1: 0xffffffff813d5790 IBS2:0x00000000013d5790
> > > > IBS_FETCH sample on cpu7	IBS0: 0x00030001186a186a IBS1: 0xffffffff8102bd00 IBS2:0x00000000013d5d00
> > > 
> > > That does not look very usable to users. So why should we merge 
> > > this new ABI in its incomplete form with no complete usecase? 
> > > Being usable is clearly not outside the scope of a new feature 
> > > ...

So is it not useful to pull ibs data with native perf tools to
userspace? Is it not useful to have a dump of the raw data too? Is it
not useful to have perf script support that allows user to easy
implement their own script to parse the data they are interested in?
IBS is for experienced users, even I don't know *everything* about
what this data can be used for, but I know people who know it. And
they want to get this data out of the kernel, using the perf_event
syscall. Maybe they also improve the perf tool with their knowledge.

Oprofile also has support for IBS in a very raw way, and there are
users for it. Remember, there are also plans to rewrite the oprofile
daemon to use perf_event. If there isn't any confidence that
perf_event will get the same features so it can be used for this,
people might better stick with that what they have.

> > > Integrating it into perf report should not be *that* hard, 
> > > you've done most of the hard work already. But without that 
> > > step we just don't know how complete and usable the whole 
> > > thing is.

We don't need a feature complete (which features?) implementation to
see use cases for this. AFAIK there is no doubt anymore about the
user/kernel interface implementation. So your argument is
questionable. If you look at other kernel features (also other perf
features) and how they got in, most of them are not perfect in the
beginning.

We also should give others the opportunity to actually use IBS, to
give feedback, to improve the tools, to work with it. Most of the
current patches wont change anymore, the code is ready. As long as the
code is not in the repostitory it is much harder for people to work
with it. They usually don't deal with some patches flying around.

We waste our time with reposting, reviewing (people seem to no longer
do this, because they are tiered), rebasing it, testing it. Do you
fear we stop working to improve the code as soon as you applied the
patches?  Have you ever had this feeling in the past? We invest a high
amount of time in all this, please let us know if this is not worth
the effort. Almost 2 years ago I posted my first IBS patches for
perf...

And, is the kernel ever ready? There is no completion at all. There is
an onging development in small steps. I don't see why you demand this
100%-fits-for-all-usecases solution, that you also don't know much
about. There isn't one, and there wont be any. Relax your position
that everything must be there in the beginning.

To me these are reasons enough to merge it.

Thanks,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Ingo Molnar]

* Robert Richter <robert.richter@amd.com> wrote:

> On 23.12.11 15:40:40, Ingo Molnar wrote:
> > 
> > * Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Fri, 2011-12-23 at 14:53 +0100, Ingo Molnar wrote:
> > > > * Robert Richter <robert.richter@amd.com> wrote:
> > > > 
> > > > > > Also, could you quote example output of "perf script report 
> > > > > > ibs"?
> > > > > 
> > > > > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x0000000000444780 IBS2:0x000000041af26780
> > > > > IBS_FETCH sample on cpu6	IBS0: 0x00170003186a186a IBS1: 0x00007f5efb44e3b2 IBS2:0x000000042fcff3b2
> > > > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065273 IBS2:0x0000000001065273
> > > > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff811a6320 IBS2:0x00000000011a6320
> > > > > IBS_FETCH sample on cpu6	IBS0: 0x01370003186a186a IBS1: 0xffffffff81065255 IBS2:0x0000000001065255
> > > > > IBS_FETCH sample on cpu7	IBS0: 0x00170004186a186a IBS1: 0x00007fbf0c687ca0 IBS2:0x000000041d345ca0
> > > > > IBS_FETCH sample on cpu7	IBS0: 0x00170003186a186a IBS1: 0x000000000043bb80 IBS2:0x000000041c351b80
> > > > > IBS_FETCH sample on cpu7	IBS0: 0x01370003186a186a IBS1: 0xffffffff813d5790 IBS2:0x00000000013d5790
> > > > > IBS_FETCH sample on cpu7	IBS0: 0x00030001186a186a IBS1: 0xffffffff8102bd00 IBS2:0x00000000013d5d00
> > > > 
> > > > That does not look very usable to users. So why should we merge 
> > > > this new ABI in its incomplete form with no complete usecase? 
> > > > Being usable is clearly not outside the scope of a new feature 
> > > > ...
> 
> So is it not useful to pull ibs data with native perf tools to 
> userspace? Is it not useful to have a dump of the raw data 
> too? Is it not useful to have perf script support that allows 
> user to easy implement their own script to parse the data they 
> are interested in? IBS is for experienced users, even I don't 
> know *everything* about what this data can be used for, but I 
> know people who know it. And they want to get this data out of 
> the kernel, using the perf_event syscall. Maybe they also 
> improve the perf tool with their knowledge.

No, i think you misunderstood me, i definitely think getting all 
the data out is perfectly fine and useful, if the hardware 
provides it. No need to make 'every' conceivable piece of IBS 
data useful straight away.

All i want is at least *one* common usecase to work fine. This 
allows us to see things in practice and it also provides the 
seed for further improvements.

Right now this does not seem to be the case: the 'report' 
portion only reports a raw hexa dump, not very useful to users.

Once something like 'perf report' works for some useful looking 
sub-case you can also tack on all the extra IBS goodies that 
specialized tools might need as well, i have no problem with 
providing that.

It's the same deal as with -rt or with LWP: niches are fine as 
long as they improve the common case as well.

Thanks,

	Ingo

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

On 23.12.11 17:39:30, Ingo Molnar wrote:
> No, i think you misunderstood me, i definitely think getting all 
> the data out is perfectly fine and useful, if the hardware 
> provides it. No need to make 'every' conceivable piece of IBS 
> data useful straight away.
> 
> All i want is at least *one* common usecase to work fine. This 
> allows us to see things in practice and it also provides the 
> seed for further improvements.
> 
> Right now this does not seem to be the case: the 'report' 
> portion only reports a raw hexa dump, not very useful to users.
> 
> Once something like 'perf report' works for some useful looking 
> sub-case you can also tack on all the extra IBS goodies that 
> specialized tools might need as well, i have no problem with 
> providing that.

Isn't that outlook I gave about pebs like implementation of the
precise bit with IBS "useful enough"? This would be on top patches
anyway, so no need to hold back current patches.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Ingo Molnar]

* Robert Richter <robert.richter@amd.com> wrote:

> > Once something like 'perf report' works for some useful 
> > looking sub-case you can also tack on all the extra IBS 
> > goodies that specialized tools might need as well, i have no 
> > problem with providing that.
> 
> Isn't that outlook I gave about pebs like implementation of 
> the precise bit with IBS "useful enough"? This would be on top 
> patches anyway, so no need to hold back current patches.

An 'outlook' is not something I can test before sending commits 
to Linus.

To help your effort we could tentatively put the patches into a 
separate tip:perf/ibs topic branch if everyone agrees otherwise, 
which can go upstream once it's complete and usable.

Thanks,

	Ingo

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

Ingo,

On 30.12.11 10:55:21, Ingo Molnar wrote:
> 
> * Robert Richter <robert.richter@amd.com> wrote:
> 
> > > Once something like 'perf report' works for some useful 
> > > looking sub-case you can also tack on all the extra IBS 
> > > goodies that specialized tools might need as well, i have no 
> > > problem with providing that.
> > 
> > Isn't that outlook I gave about pebs like implementation of 
> > the precise bit with IBS "useful enough"? This would be on top 
> > patches anyway, so no need to hold back current patches.
> 
> An 'outlook' is not something I can test before sending commits 
> to Linus.

The question was more if this is the direction you think may make
sense to go to. Of course, I would then implement and send patches for
this.

> To help your effort we could tentatively put the patches into a 
> separate tip:perf/ibs topic branch if everyone agrees otherwise, 
> which can go upstream once it's complete and usable.

This would be very helpful for me. So far I see following patches for
this on top of today's tip/perf/core (623ec99):

08e232d perf, x86: Implement IBS event configuration
05efba4 perf, x86: Implement IBS interrupt handler
b0532b2 perf, x86: Implement IBS pmu control ops
56ccf1a perf, x86: Implement 64 bit counter support for IBS
98e655c perf tool: Parse general/raw events from sysfs
aac22da perf tools: Add pmu mappings to header information
f1f062d perf script: Add script to collect and display IBS samples

Only 'perf tools: Add pmu mappings to header information' applies with
conflicts, so I could resend an updated version. This patch is also
independent from the other patches and can be applied separately.

If you wish I also can send all patches again, but they would be
unchanged anyway (except that one with the conflict).

Peter and Arnaldo,

please agree with a separate tip:perf/ibs development branch. It would
be easier to all of us because we don't have the effort of reviewing
patches again that will not change anymore.

Thanks,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Ingo Molnar]

* Robert Richter <robert.richter@amd.com> wrote:

> > To help your effort we could tentatively put the patches 
> > into a separate tip:perf/ibs topic branch if everyone agrees 
> > otherwise, which can go upstream once it's complete and 
> > usable.
> 
> This would be very helpful for me. So far I see following 
> patches for this on top of today's tip/perf/core (623ec99):
> 
> 08e232d perf, x86: Implement IBS event configuration
> 05efba4 perf, x86: Implement IBS interrupt handler
> b0532b2 perf, x86: Implement IBS pmu control ops
> 56ccf1a perf, x86: Implement 64 bit counter support for IBS
> 98e655c perf tool: Parse general/raw events from sysfs
> aac22da perf tools: Add pmu mappings to header information
> f1f062d perf script: Add script to collect and display IBS samples

I've applied the following 4 kernel patches to perf/x86-ibs:

 db98c5faf8cb: perf/x86: Implement 64-bit counter support for IBS
 4db2e8e6500d: perf/x86: Implement IBS pmu control ops
 b7074f1fbd61: perf/x86: Implement IBS interrupt handler
 510419435c69: perf/x86: Implement IBS event configuration

and pushed it out.

We can apply any tooling changes to this branch as well.

I suspect being able to skid-less profile on AMD CPUs, using 
IBS, would be a useful feature to users. What would be required 
for that to work?

Thanks,

	Ingo

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

Ingo,

On 08.03.12 13:19:24, Ingo Molnar wrote:
> I've applied the following 4 kernel patches to perf/x86-ibs:
> 
>  db98c5faf8cb: perf/x86: Implement 64-bit counter support for IBS
>  4db2e8e6500d: perf/x86: Implement IBS pmu control ops
>  b7074f1fbd61: perf/x86: Implement IBS interrupt handler
>  510419435c69: perf/x86: Implement IBS event configuration
> 
> and pushed it out.
> 
> We can apply any tooling changes to this branch as well.
> 
> I suspect being able to skid-less profile on AMD CPUs, using 
> IBS, would be a useful feature to users. What would be required 
> for that to work?

thanks for putting this into tip. This helps a lot.

I am just looking into skid-less sampling. The effort of attaching the
rip taken from the IBS sample for events 0x76/0xc1 should be feasable.

In between I started the implementation of ibs pseudo events as
described here:

 Appendix F Guide to Instruction-Based Sampling
 http://support.amd.com/us/Processor_TechDocs/47414_15h_sw_opt_guide.pdf

This includes kernel side filtering and ibs support for the perf tool.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Robert Richter]

Ingo,

On 09.03.12 12:41:12, Robert Richter wrote:
> > I suspect being able to skid-less profile on AMD CPUs, using 
> > IBS, would be a useful feature to users. What would be required 
> > for that to work?
> 
> thanks for putting this into tip. This helps a lot.
> 
> I am just looking into skid-less sampling. The effort of attaching the
> rip taken from the IBS sample for events 0x76/0xc1 should be feasable.

I have some patches ready for release after the merge window. I
noticed conflicts between my development tree on top of
tip/perf/x86-ibs and tip/perf/core. Could you merge tip/perf/core into
tip/perf/x86-ibs? I will rebase my current patches then. This avoids
diverging the trees to much and reduces later conflicts.

Thanks,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

Re: [PATCH 4/4] perf script: Add script to collect and display IBS samples

[Ingo Molnar]

* Robert Richter <robert.richter@amd.com> wrote:

> Ingo,
> 
> On 09.03.12 12:41:12, Robert Richter wrote:
> > > I suspect being able to skid-less profile on AMD CPUs, using 
> > > IBS, would be a useful feature to users. What would be required 
> > > for that to work?
> > 
> > thanks for putting this into tip. This helps a lot.
> > 
> > I am just looking into skid-less sampling. The effort of attaching the
> > rip taken from the IBS sample for events 0x76/0xc1 should be feasable.
> 
> I have some patches ready for release after the merge window. 
> I noticed conflicts between my development tree on top of 
> tip/perf/x86-ibs and tip/perf/core. Could you merge 
> tip/perf/core into tip/perf/x86-ibs? I will rebase my current 
> patches then. This avoids diverging the trees to much and 
> reduces later conflicts.

Feel free to do the merge yourself - that way you can also test 
the merged tree.

Thanks,

	Ingo