Skip to contentSkip to conversation

perf/core improvements and fixes

GIT PULL New Arnaldo Carvalho de Melo 3 participants 44 messages May 26, 2015 – Jun 5, 2015 perf events

lore
Share & tools
lore

Arnaldo Carvalho de Melo

author maintainer
#0 lore raw

Hi Ingo,

	Test built on Fedora21 x86_64, RHEL (5.11 with NO_AUXTRACE=1

NO_LIBPERL=1 NO_LIBNUMA=1, 6.6 and 7.1) all x86_64.

Please consider applying,

- Arnaldo

The following changes since commit d499c106843afa0703a68c64662bf42a16421aec:

Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2015-05-20 13:23:55 +0200)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo

for you to fetch changes up to 264ed8843fe2e4c24422ff61de1e3db609106445:

perf tools: Put itrace options into an asciidoc include (2015-05-26 13:21:08 -0300)

----------------------------------------------------------------
perf/core improvements and fixes:

New features:

- Intel PT support, should be complete now and possible to test it with what we already have in the kernel, go, test it and report problems on lkml, I'm sure Adrian will chime in if something doesn't work as documented. (Adrian Hunter)

- Add option in 'perf sched' to merge like comms to lat output (Josef Bacik)

Infrastructure:

- Use atomic.h for various pre-existing reference counts (Arnaldo Carvalho de Melo)

- Leg work for refcounting 'struct map' (Arnaldo Carvalho de Melo)

- Assign default value for some pointers (Martin Liška)

- Improve setting of gcc debug option (Martin Liška)

- Separate the tests and tools in installation (Nam T. Nguyen)

- Reduce number of arguments of hist_entry_iter__add() (Namhyung Kim)

- DSO data cache fixes (Namhyung Kim)

----------------------------------------------------------------
Adrian Hunter (19):
perf tools: Fix function declarations needed by parse-events.y perf tools: Fix parse_events_error dereferences
perf build: Fix libunwind feature detection on 32-bit x86
perf session: Fix perf_session__peek_event()
perf tools: Disallow PMU events intel_pt and intel_bts until there is support perf auxtrace: Add Intel PT as an AUX area tracing type
perf tools: Add Intel PT packet decoder
perf tools: Add Intel PT instruction decoder
perf tools: Add Intel PT log
perf tools: Add Intel PT decoder
perf tools: Add Intel PT support
perf tools: Take Intel PT into use
perf tools: Allow auxtrace data alignment
perf tools: Add Intel BTS support
perf tools: Output sample flags and insn_len from intel_pt
perf tools: Output sample flags and insn_len from intel_bts
perf tools: Intel PT to always update thread stack trace number perf tools: Intel BTS to always update thread stack trace number perf tools: Put itrace options into an asciidoc include

Arnaldo Carvalho de Melo (10):
perf hists: Rename add_hist_entry to hists__findnew_entry perf comm: Use atomic.h for refcounting
perf machine: Do not call map_groups__delete(), drop refcnt instead perf tools: Rename maps__next
perf tools: Remove redundant initialization of thread linkage members perf tools: Nuke unused map_groups__flush()
perf tools: Import rb_erase_init from block/ in the kernel sources perf machine: Mark removed threads as such
perf tools: Leave DSO destruction to the map destruction perf tools: Use maps__first()/map__next()

Josef Bacik (1):
perf sched: Add option to merge like comms to lat output

Martin Liska (1):
perf tools: Improve setting of gcc debug option

Martin Liška (1):
perf tools: Assign default value for some pointers

Nam T. Nguyen (1):
perf tools: Separate the tests and tools in installation

Namhyung Kim (4):
perf hists: Reducing arguments of hist_entry_iter__add() perf tools: Fix dso__data_read_offset() file opening perf tools: Get rid of dso__data_fd() from dso__data_size() perf tools: Add dso__data_get/put_fd()

 tools/build/Makefile.build                         |    2 +
 tools/perf/.gitignore                              |    2 +
 tools/perf/Documentation/intel-bts.txt             |   69 +
 tools/perf/Documentation/intel-pt.txt              |  467 +++++
 tools/perf/Documentation/itrace.txt                |   22 +
 tools/perf/Documentation/perf-inject.txt           |   23 +-
 tools/perf/Documentation/perf-report.txt           |   23 +-
 tools/perf/Documentation/perf-script.txt           |   23 +-
 tools/perf/Makefile.perf                           |   18 +-
 tools/perf/arch/common.c                           |    2 +-
 tools/perf/arch/x86/util/Build                     |    5 +
 tools/perf/arch/x86/util/auxtrace.c                |   83 +
 tools/perf/arch/x86/util/intel-bts.c               |  458 +++++
 tools/perf/arch/x86/util/intel-pt.c                |  752 ++++++++
 tools/perf/arch/x86/util/pmu.c                     |   18 +
 tools/perf/builtin-report.c                        |    9 +-
 tools/perf/builtin-sched.c                         |   77 +-
 tools/perf/builtin-top.c                           |    7 +-
 tools/perf/config/Makefile                         |    4 +-
 tools/perf/config/utilities.mak                    |   19 +
 tools/perf/tests/dso-data.c                        |   11 +
 tools/perf/tests/hists_cumulate.c                  |    6 +-
 tools/perf/tests/hists_filter.c                    |    4 +-
 tools/perf/tests/hists_output.c                    |    6 +-
 tools/perf/tests/vmlinux-kallsyms.c                |   34 +-
 tools/perf/util/Build                              |    3 +
 tools/perf/util/auxtrace.c                         |   16 +-
 tools/perf/util/auxtrace.h                         |    3 +
 tools/perf/util/comm.c                             |   13 +-
 tools/perf/util/dso.c                              |   88 +-
 tools/perf/util/dso.h                              |   13 +-
 tools/perf/util/event.c                            |    7 +-
 tools/perf/util/hist.c                             |   24 +-
 tools/perf/util/hist.h                             |    1 -
 tools/perf/util/include/linux/rbtree.h             |   14 +
 tools/perf/util/intel-bts.c                        |  921 ++++++++++
 tools/perf/util/intel-bts.h                        |   43 +
 tools/perf/util/intel-pt-decoder/Build             |   14 +
 .../perf/util/intel-pt-decoder/intel-pt-decoder.c  | 1758 ++++++++++++++++++
 .../perf/util/intel-pt-decoder/intel-pt-decoder.h  |  102 ++
 .../util/intel-pt-decoder/intel-pt-insn-decoder.c  |  246 +++
 .../util/intel-pt-decoder/intel-pt-insn-decoder.h  |   65 +
 tools/perf/util/intel-pt-decoder/intel-pt-log.c    |  155 ++
 tools/perf/util/intel-pt-decoder/intel-pt-log.h    |   52 +
 .../util/intel-pt-decoder/intel-pt-pkt-decoder.c   |  400 +++++
 .../util/intel-pt-decoder/intel-pt-pkt-decoder.h   |   64 +
 tools/perf/util/intel-pt.c                         | 1895 ++++++++++++++++++++
 tools/perf/util/intel-pt.h                         |   51 +
 tools/perf/util/machine.c                          |    6 +-
 tools/perf/util/map.c                              |   31 +-
 tools/perf/util/map.h                              |    6 +-
 tools/perf/util/parse-events.c                     |   18 +-
 tools/perf/util/parse-events.h                     |    6 +
 tools/perf/util/parse-events.y                     |    6 +-
 tools/perf/util/probe-event.c                      |    9 +-
 tools/perf/util/session.c                          |    6 +-
 tools/perf/util/symbol.c                           |   25 +-
 tools/perf/util/thread.c                           |    2 -
 tools/perf/util/trace-event-parse.c                |    2 +-
 tools/perf/util/unwind-libunwind.c                 |   11 +-
 60 files changed, 7977 insertions(+), 243 deletions(-)
 create mode 100644 tools/perf/Documentation/intel-bts.txt
 create mode 100644 tools/perf/Documentation/intel-pt.txt
 create mode 100644 tools/perf/Documentation/itrace.txt
 create mode 100644 tools/perf/arch/x86/util/auxtrace.c
 create mode 100644 tools/perf/arch/x86/util/intel-bts.c
 create mode 100644 tools/perf/arch/x86/util/intel-pt.c
 create mode 100644 tools/perf/arch/x86/util/pmu.c
 create mode 100644 tools/perf/util/intel-bts.c
 create mode 100644 tools/perf/util/intel-bts.h
 create mode 100644 tools/perf/util/intel-pt-decoder/Build
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-log.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-log.h
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.h
 create mode 100644 tools/perf/util/intel-pt.c
 create mode 100644 tools/perf/util/intel-pt.h
author maintainer
#1 lore raw

PATCH 1/37 perf tools: Separate the tests and tools in installation

From: "Nam T. Nguyen" <[email protected]>

This refactors out install-bin to install-tests and install-tools so that downstream could opt to only install the tools, and not the tests.

---
 tools/perf/Makefile.perf | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
tools/perf/Makefile.perf +5 -1
index 03409cc02117..5816a3bb7e9f 100644
@@ -464,7 +464,7 @@ check: $(OUTPUT)common-cmds.h
 
 install-gtk:
 
-install-bin: all install-gtk
+install-tools: all install-gtk
 	$(call QUIET_INSTALL, binaries) \
 		$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'; \
 		$(INSTALL) $(OUTPUT)perf '$(DESTDIR_SQ)$(bindir_SQ)'; \
@@ -502,12 +502,16 @@ endif
 	$(call QUIET_INSTALL, perf_completion-script) \
 		$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(sysconfdir_SQ)/bash_completion.d'; \
 		$(INSTALL) perf-completion.sh '$(DESTDIR_SQ)$(sysconfdir_SQ)/bash_completion.d/perf'
+
+install-tests: all install-gtk
 	$(call QUIET_INSTALL, tests) \
 		$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests'; \
 		$(INSTALL) tests/attr.py '$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests'; \
 		$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests/attr'; \
 		$(INSTALL) tests/attr/* '$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests/attr'
 
+install-bin: install-tools install-tests
+
 install: install-bin try-install-man install-traceevent-plugins
 
 install-python_ext:
Signature · 1 line
2.1.0
author maintainer
#2 lore raw

PATCH 2/37 perf tools: Fix function declarations needed by parse-events.y

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Patch "perf tools: Add location to pmu event terms" moved declarations for parse_events_term__num() and parse_events_term__str() so that they were no longer visible in parse-events.y. That can result in segfaults as the arguments no longer need match the function prototype.

Move the declarations back, changing YYLTYPE pointers to pointers-to-void because YYLTYPE is not generated until parse-events.y is processed.

---
 tools/perf/util/parse-events.c | 16 ++++++++--------
 tools/perf/util/parse-events.h |  6 ++++++
 2 files changed, 14 insertions(+), 8 deletions(-)
tools/perf/util/parse-events.c +8 -8
index 80a50fdb6d8a..78032d887c1a 100644
@@ -25,12 +25,6 @@
 extern int parse_events_debug;
 #endif
 int parse_events_parse(void *data, void *scanner);
-int parse_events_term__num(struct parse_events_term **term,
-			   int type_term, char *config, u64 num,
-			   YYLTYPE *loc_term, YYLTYPE *loc_val);
-int parse_events_term__str(struct parse_events_term **term,
-			   int type_term, char *config, char *str,
-			   YYLTYPE *loc_term, YYLTYPE *loc_val);
 
 static struct perf_pmu_event_symbol *perf_pmu_events_list;
 /*
@@ -1601,8 +1595,11 @@ static int new_term(struct parse_events_term **_term, int type_val,
 
 int parse_events_term__num(struct parse_events_term **term,
 			   int type_term, char *config, u64 num,
-			   YYLTYPE *loc_term, YYLTYPE *loc_val)
+			   void *loc_term_, void *loc_val_)
 {
+	YYLTYPE *loc_term = loc_term_;
+	YYLTYPE *loc_val = loc_val_;
+
 	return new_term(term, PARSE_EVENTS__TERM_TYPE_NUM, type_term,
 			config, NULL, num,
 			loc_term ? loc_term->first_column : 0,
@@ -1611,8 +1608,11 @@ int parse_events_term__num(struct parse_events_term **term,
 
 int parse_events_term__str(struct parse_events_term **term,
 			   int type_term, char *config, char *str,
-			   YYLTYPE *loc_term, YYLTYPE *loc_val)
+			   void *loc_term_, void *loc_val_)
 {
+	YYLTYPE *loc_term = loc_term_;
+	YYLTYPE *loc_val = loc_val_;
+
 	return new_term(term, PARSE_EVENTS__TERM_TYPE_STR, type_term,
 			config, str, 0,
 			loc_term ? loc_term->first_column : 0,
tools/perf/util/parse-events.h +6 -0
index e236f1b6ac6f..131f29b2f132 100644
@@ -98,6 +98,12 @@ struct parse_events_terms {
 };
 
 int parse_events__is_hardcoded_term(struct parse_events_term *term);
+int parse_events_term__num(struct parse_events_term **term,
+			   int type_term, char *config, u64 num,
+			   void *loc_term, void *loc_val);
+int parse_events_term__str(struct parse_events_term **term,
+			   int type_term, char *config, char *str,
+			   void *loc_term, void *loc_val);
 int parse_events_term__sym_hw(struct parse_events_term **term,
 			      char *config, unsigned idx);
 int parse_events_term__clone(struct parse_events_term **new,
Signature · 1 line
2.1.0
author maintainer
#3 lore raw

PATCH 3/37 perf tools: Fix parse_events_error dereferences

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Parse errors can be reported in struct parse_events_error but the pointer passed is optional and can be NULL. Ensure it is not NULL before dereferencing it.

---
 tools/perf/util/parse-events.c | 2 ++
 tools/perf/util/parse-events.y | 6 ++++--
 2 files changed, 6 insertions(+), 2 deletions(-)
tools/perf/util/parse-events.c +2 -0
index 78032d887c1a..2a4d1ec02846 100644
@@ -1659,6 +1659,8 @@ void parse_events_evlist_error(struct parse_events_evlist *data,
 {
 	struct parse_events_error *err = data->error;
 
+	if (!err)
+		return;
 	err->idx = idx;
 	err->str = strdup(str);
 	WARN_ONCE(!err->str, "WARNING: failed to allocate error string");
tools/perf/util/parse-events.y +4 -2
index 3d11e00243e3..591905a02b92 100644
@@ -389,8 +389,10 @@ PE_NAME ':' PE_NAME
 	if (parse_events_add_tracepoint(list, &data->idx, $1, $3)) {
 		struct parse_events_error *error = data->error;
 
-		error->idx = @1.first_column;
-		error->str = strdup("unknown tracepoint");
+		if (error) {
+			error->idx = @1.first_column;
+			error->str = strdup("unknown tracepoint");
+		}
 		return -1;
 	}
 	$$ = list;
Signature · 1 line
2.1.0
author maintainer
#4 lore raw

PATCH 4/37 perf build: Fix libunwind feature detection on 32-bit x86

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

The libunwind feature would never detect because of the following error:

  $ cat tools/build/feature/test-libunwind.make.output
  /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libunwind-x86.so: undefined reference to `lzma_stream_buffer_decode'
  /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libunwind-x86.so: undefined reference to `lzma_index_uncompressed_size'
  /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libunwind-x86.so: undefined reference to `lzma_index_end'
  /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libunwind-x86.so: undefined reference to `lzma_index_buffer_decode'
  /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libunwind-x86.so: undefined reference to `lzma_stream_footer_decode'
  /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/libunwind-x86.so: undefined reference to `lzma_index_size'
  collect2: error: ld returned 1 exit status

Fix by adding -llzma and re-ordering to match the dependencies.

---
 tools/perf/config/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/config/Makefile +1 -1
index 1b957a1272d0..e3b3724e73ff 100644
@@ -32,7 +32,7 @@ ifeq ($(ARCH),x86)
     LIBUNWIND_LIBS = -lunwind -lunwind-x86_64
     $(call detected,CONFIG_X86_64)
   else
-    LIBUNWIND_LIBS = -lunwind -lunwind-x86
+    LIBUNWIND_LIBS = -lunwind-x86 -llzma -lunwind
   endif
   NO_PERF_REGS := 0
 endif
Signature · 1 line
2.1.0
author maintainer
#5 lore raw

PATCH 5/37 perf session: Fix perf_session__peek_event()

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

perf_session__peek_event() generally leverages there being a single mmap of the perf.data file, however on 32-bit platforms when there is more that 32MiB of data, then there are multiple mmaps, so perf_session__peek_event() reads from the file.

In that case a couple of bugs were exposed (note how the seg. fault appears with >32M of data):

   $ perf record --per-thread -e intel_bts// ../rtit-tests/loopy 1000000
   [ perf record: Woken up 13 times to write data ]
   [ perf record: Captured and wrote 24.568 MB perf.data ]
   $ perf script > /dev/null
   $ perf record --per-thread -e intel_bts// ../rtit-tests/loopy 10000000
   [ perf record: Woken up 136 times to write data ]
   [ perf record: Captured and wrote 270.794 MB perf.data ]
   $ perf script > /dev/null
   Segmentation fault (core dumped)

The wrong address was being passed to the readn() function and the buffer size was not being checked.

---
 tools/perf/util/session.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
tools/perf/util/session.c +3 -3
index e722107f932a..39fe09d5a87e 100644
@@ -1182,7 +1182,7 @@ int perf_session__peek_event(struct perf_session *session, off_t file_offset,
 		return -1;
 
 	if (lseek(fd, file_offset, SEEK_SET) == (off_t)-1 ||
-	    readn(fd, &buf, hdr_sz) != (ssize_t)hdr_sz)
+	    readn(fd, buf, hdr_sz) != (ssize_t)hdr_sz)
 		return -1;
 
 	event = (union perf_event *)buf;
@@ -1190,12 +1190,12 @@ int perf_session__peek_event(struct perf_session *session, off_t file_offset,
 	if (session->header.needs_swap)
 		perf_event_header__bswap(&event->header);
 
-	if (event->header.size < hdr_sz)
+	if (event->header.size < hdr_sz || event->header.size > buf_sz)
 		return -1;
 
 	rest = event->header.size - hdr_sz;
 
-	if (readn(fd, &buf, rest) != (ssize_t)rest)
+	if (readn(fd, buf, rest) != (ssize_t)rest)
 		return -1;
 
 	if (session->header.needs_swap)
Signature · 1 line
2.1.0
author maintainer
#6 lore raw

PATCH 6/37 perf hists: Reducing arguments of hist_entry_iter__add()

In reply to Arnaldo Carvalho de Melo

From: Namhyung Kim <[email protected]>

The evsel and sample arguments are to set iter for later use. As it also receives an iter as another argument, just set them before calling the function.

---
 tools/perf/builtin-report.c       | 9 +++++----
 tools/perf/builtin-top.c          | 7 ++++---
 tools/perf/tests/hists_cumulate.c | 6 ++++--
 tools/perf/tests/hists_filter.c   | 4 +++-
 tools/perf/tests/hists_output.c   | 6 ++++--
 tools/perf/util/hist.c            | 8 ++------
 tools/perf/util/hist.h            | 1 -
 7 files changed, 22 insertions(+), 19 deletions(-)
tools/perf/builtin-report.c +5 -4
index 92fca2157e5e..56025d90622f 100644
@@ -139,8 +139,10 @@ static int process_sample_event(struct perf_tool *tool,
 	struct report *rep = container_of(tool, struct report, tool);
 	struct addr_location al;
 	struct hist_entry_iter iter = {
-		.hide_unresolved = rep->hide_unresolved,
-		.add_entry_cb = hist_iter__report_callback,
+		.evsel 			= evsel,
+		.sample 		= sample,
+		.hide_unresolved 	= rep->hide_unresolved,
+		.add_entry_cb 		= hist_iter__report_callback,
 	};
 	int ret = 0;
 
@@ -168,8 +170,7 @@ static int process_sample_event(struct perf_tool *tool,
 	if (al.map != NULL)
 		al.map->dso->hit = 1;
 
-	ret = hist_entry_iter__add(&iter, &al, evsel, sample, rep->max_stack,
-				   rep);
+	ret = hist_entry_iter__add(&iter, &al, rep->max_stack, rep);
 	if (ret < 0)
 		pr_debug("problem adding hist entry, skipping event\n");
 out_put:
tools/perf/builtin-top.c +4 -3
index a19351728f0f..6b987424d015 100644
@@ -775,7 +775,9 @@ static void perf_event__process_sample(struct perf_tool *tool,
 	if (al.sym == NULL || !al.sym->ignore) {
 		struct hists *hists = evsel__hists(evsel);
 		struct hist_entry_iter iter = {
-			.add_entry_cb = hist_iter__top_callback,
+			.evsel		= evsel,
+			.sample 	= sample,
+			.add_entry_cb 	= hist_iter__top_callback,
 		};
 
 		if (symbol_conf.cumulate_callchain)
@@ -785,8 +787,7 @@ static void perf_event__process_sample(struct perf_tool *tool,
 
 		pthread_mutex_lock(&hists->lock);
 
-		err = hist_entry_iter__add(&iter, &al, evsel, sample,
-					   top->max_stack, top);
+		err = hist_entry_iter__add(&iter, &al, top->max_stack, top);
 		if (err < 0)
 			pr_err("Problem incrementing symbol period, skipping event\n");
 
tools/perf/tests/hists_cumulate.c +4 -2
index 620f626e5b35..7d82c8be5e36 100644
@@ -87,6 +87,8 @@ static int add_hist_entries(struct hists *hists, struct machine *machine)
 			},
 		};
 		struct hist_entry_iter iter = {
+			.evsel = evsel,
+			.sample	= &sample,
 			.hide_unresolved = false,
 		};
 
@@ -104,8 +106,8 @@ static int add_hist_entries(struct hists *hists, struct machine *machine)
 						  &sample) < 0)
 			goto out;
 
-		if (hist_entry_iter__add(&iter, &al, evsel, &sample,
-					 PERF_MAX_STACK_DEPTH, NULL) < 0) {
+		if (hist_entry_iter__add(&iter, &al, PERF_MAX_STACK_DEPTH,
+					 NULL) < 0) {
 			addr_location__put(&al);
 			goto out;
 		}
tools/perf/tests/hists_filter.c +3 -1
index 82e1ee52e024..ce48775e6ada 100644
@@ -63,6 +63,8 @@ static int add_hist_entries(struct perf_evlist *evlist,
 				},
 			};
 			struct hist_entry_iter iter = {
+				.evsel = evsel,
+				.sample = &sample,
 				.ops = &hist_iter_normal,
 				.hide_unresolved = false,
 			};
@@ -81,7 +83,7 @@ static int add_hist_entries(struct perf_evlist *evlist,
 							  &sample) < 0)
 				goto out;
 
-			if (hist_entry_iter__add(&iter, &al, evsel, &sample,
+			if (hist_entry_iter__add(&iter, &al,
 						 PERF_MAX_STACK_DEPTH, NULL) < 0) {
 				addr_location__put(&al);
 				goto out;
tools/perf/tests/hists_output.c +4 -2
index fd7ec4f9aeb4..adbebc852cc8 100644
@@ -57,6 +57,8 @@ static int add_hist_entries(struct hists *hists, struct machine *machine)
 			},
 		};
 		struct hist_entry_iter iter = {
+			.evsel = evsel,
+			.sample = &sample,
 			.ops = &hist_iter_normal,
 			.hide_unresolved = false,
 		};
@@ -70,8 +72,8 @@ static int add_hist_entries(struct hists *hists, struct machine *machine)
 						  &sample) < 0)
 			goto out;
 
-		if (hist_entry_iter__add(&iter, &al, evsel, &sample,
-					 PERF_MAX_STACK_DEPTH, NULL) < 0) {
+		if (hist_entry_iter__add(&iter, &al, PERF_MAX_STACK_DEPTH,
+					 NULL) < 0) {
 			addr_location__put(&al);
 			goto out;
 		}
tools/perf/util/hist.c +2 -6
index 338770679863..2504b5b1a308 100644
@@ -851,19 +851,15 @@ const struct hist_iter_ops hist_iter_cumulative = {
 };
 
 int hist_entry_iter__add(struct hist_entry_iter *iter, struct addr_location *al,
-			 struct perf_evsel *evsel, struct perf_sample *sample,
 			 int max_stack_depth, void *arg)
 {
 	int err, err2;
 
-	err = sample__resolve_callchain(sample, &iter->parent, evsel, al,
-					max_stack_depth);
+	err = sample__resolve_callchain(iter->sample, &iter->parent,
+					iter->evsel, al, max_stack_depth);
 	if (err)
 		return err;
 
-	iter->evsel = evsel;
-	iter->sample = sample;
-
 	err = iter->ops->prepare_entry(iter, al);
 	if (err)
 		goto out;
tools/perf/util/hist.h +0 -1
index 9f31b89a527a..5ed8d9c22981 100644
@@ -111,7 +111,6 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
 				      u64 weight, u64 transaction,
 				      bool sample_self);
 int hist_entry_iter__add(struct hist_entry_iter *iter, struct addr_location *al,
-			 struct perf_evsel *evsel, struct perf_sample *sample,
 			 int max_stack_depth, void *arg);
 
 int64_t hist_entry__cmp(struct hist_entry *left, struct hist_entry *right);
Signature · 1 line
2.1.0
author maintainer
#7 lore raw

PATCH 7/37 perf hists: Rename add_hist_entry to hists__findnew_entry

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

To match the convention used elsewhere.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/hist.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
tools/perf/util/hist.c +8 -8
index 2504b5b1a308..f53d017c7c22 100644
@@ -362,10 +362,10 @@ static u8 symbol__parent_filter(const struct symbol *parent)
 	return 0;
 }
 
-static struct hist_entry *add_hist_entry(struct hists *hists,
-					 struct hist_entry *entry,
-					 struct addr_location *al,
-					 bool sample_self)
+static struct hist_entry *hists__findnew_entry(struct hists *hists,
+					       struct hist_entry *entry,
+					       struct addr_location *al,
+					       bool sample_self)
 {
 	struct rb_node **p;
 	struct rb_node *parent = NULL;
@@ -468,7 +468,7 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
 		.transaction = transaction,
 	};
 
-	return add_hist_entry(hists, &entry, al, sample_self);
+	return hists__findnew_entry(hists, &entry, al, sample_self);
 }
 
 static int
@@ -548,9 +548,9 @@ iter_finish_mem_entry(struct hist_entry_iter *iter,
 
 out:
 	/*
-	 * We don't need to free iter->priv (mem_info) here since
-	 * the mem info was either already freed in add_hist_entry() or
-	 * passed to a new hist entry by hist_entry__new().
+	 * We don't need to free iter->priv (mem_info) here since the mem info
+	 * was either already freed in hists__findnew_entry() or passed to a
+	 * new hist entry by hist_entry__new().
 	 */
 	iter->priv = NULL;
 
Signature · 1 line
2.1.0
author maintainer
#8 lore raw

PATCH 8/37 perf comm: Use atomic.h for refcounting

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

Now that we have atomic.h, we should convert all of the existing refcounts to use it.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/comm.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)
tools/perf/util/comm.c +9 -4
index b2bb59df65e1..21b7ff382c3f 100644
@@ -2,24 +2,27 @@
 #include "util.h"
 #include <stdlib.h>
 #include <stdio.h>
+#include <linux/atomic.h>
 
 struct comm_str {
 	char *str;
 	struct rb_node rb_node;
-	int ref;
+	atomic_t refcnt;
 };
 
 /* Should perhaps be moved to struct machine */
 static struct rb_root comm_str_root;
 
-static void comm_str__get(struct comm_str *cs)
+static struct comm_str *comm_str__get(struct comm_str *cs)
 {
-	cs->ref++;
+	if (cs)
+		atomic_inc(&cs->refcnt);
+	return cs;
 }
 
 static void comm_str__put(struct comm_str *cs)
 {
-	if (!--cs->ref) {
+	if (cs && atomic_dec_and_test(&cs->refcnt)) {
 		rb_erase(&cs->rb_node, &comm_str_root);
 		zfree(&cs->str);
 		free(cs);
@@ -40,6 +43,8 @@ static struct comm_str *comm_str__alloc(const char *str)
 		return NULL;
 	}
 
+	atomic_set(&cs->refcnt, 0);
+
 	return cs;
 }
 
Signature · 1 line
2.1.0
author maintainer
#9 lore raw

PATCH 9/37 perf machine: Do not call map_groups__delete(), drop refcnt instead

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

It could be used somewhere, so just call map__groups_put() to make sure we don't delete it prematurely

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/machine.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/machine.c +1 -1
index daa55910ff28..7ec3188d3cb3 100644
@@ -333,7 +333,7 @@ static void machine__update_thread_pid(struct machine *machine,
 		if (!map_groups__empty(th->mg))
 			pr_err("Discarding thread maps for %d:%d\n",
 			       th->pid_, th->tid);
-		map_groups__delete(th->mg);
+		map_groups__put(th->mg);
 	}
 
 	th->mg = map_groups__get(leader->mg);
Signature · 1 line
2.1.0
author maintainer
#10 lore raw

PATCH 10/37 perf tools: Fix dso__data_read_offset() file opening

In reply to Arnaldo Carvalho de Melo

From: Namhyung Kim <[email protected]>

When dso__data_read_offset/addr() is called without prior dso__data_fd() (or other functions which call it internally), it failed to open dso in data_file_size() since its binary type was not identified.

However calling dso__data_fd() in dso__data_read_offset() will hurt performance as it grabs a global lock everytime. So factor out the loop on the binary type in dso__data_fd(), and call it from both.

---
 tools/perf/util/dso.c | 59 ++++++++++++++++++++++++++++-----------------------
 1 file changed, 32 insertions(+), 27 deletions(-)
tools/perf/util/dso.c +32 -27
index 1b96c8d18435..516e0c25ea16 100644
@@ -440,15 +440,7 @@ void dso__data_close(struct dso *dso)
 	pthread_mutex_unlock(&dso__data_open_lock);
 }
 
-/**
- * dso__data_fd - Get dso's data file descriptor
- * @dso: dso object
- * @machine: machine object
- *
- * External interface to find dso's file, open it and
- * returns file descriptor.
- */
-int dso__data_fd(struct dso *dso, struct machine *machine)
+static void try_to_open_dso(struct dso *dso, struct machine *machine)
 {
 	enum dso_binary_type binary_type_data[] = {
 		DSO_BINARY_TYPE__BUILD_ID_CACHE,
@@ -457,13 +449,8 @@ int dso__data_fd(struct dso *dso, struct machine *machine)
 	};
 	int i = 0;
 
-	if (dso->data.status == DSO_DATA_STATUS_ERROR)
-		return -1;
-
-	pthread_mutex_lock(&dso__data_open_lock);
-
 	if (dso->data.fd >= 0)
-		goto out;
+		return;
 
 	if (dso->binary_type != DSO_BINARY_TYPE__NOT_FOUND) {
 		dso->data.fd = open_dso(dso, machine);
@@ -483,8 +470,25 @@ out:
 		dso->data.status = DSO_DATA_STATUS_OK;
 	else
 		dso->data.status = DSO_DATA_STATUS_ERROR;
+}
+
+/**
+ * dso__data_fd - Get dso's data file descriptor
+ * @dso: dso object
+ * @machine: machine object
+ *
+ * External interface to find dso's file, open it and
+ * returns file descriptor.
+ */
+int dso__data_fd(struct dso *dso, struct machine *machine)
+{
+	if (dso->data.status == DSO_DATA_STATUS_ERROR)
+		return -1;
 
+	pthread_mutex_lock(&dso__data_open_lock);
+	try_to_open_dso(dso, machine);
 	pthread_mutex_unlock(&dso__data_open_lock);
+
 	return dso->data.fd;
 }
 
@@ -609,13 +613,12 @@ dso_cache__read(struct dso *dso, struct machine *machine,
 		 * dso->data.fd might be closed if other thread opened another
 		 * file (dso) due to open file limit (RLIMIT_NOFILE).
 		 */
+		try_to_open_dso(dso, machine);
+
 		if (dso->data.fd < 0) {
-			dso->data.fd = open_dso(dso, machine);
-			if (dso->data.fd < 0) {
-				ret = -errno;
-				dso->data.status = DSO_DATA_STATUS_ERROR;
-				break;
-			}
+			ret = -errno;
+			dso->data.status = DSO_DATA_STATUS_ERROR;
+			break;
 		}
 
 		cache_offset = offset & DSO__DATA_CACHE_MASK;
@@ -702,19 +705,21 @@ static int data_file_size(struct dso *dso, struct machine *machine)
 	if (dso->data.file_size)
 		return 0;
 
+	if (dso->data.status == DSO_DATA_STATUS_ERROR)
+		return -1;
+
 	pthread_mutex_lock(&dso__data_open_lock);
 
 	/*
 	 * dso->data.fd might be closed if other thread opened another
 	 * file (dso) due to open file limit (RLIMIT_NOFILE).
 	 */
+	try_to_open_dso(dso, machine);
+
 	if (dso->data.fd < 0) {
-		dso->data.fd = open_dso(dso, machine);
-		if (dso->data.fd < 0) {
-			ret = -errno;
-			dso->data.status = DSO_DATA_STATUS_ERROR;
-			goto out;
-		}
+		ret = -errno;
+		dso->data.status = DSO_DATA_STATUS_ERROR;
+		goto out;
 	}
 
 	if (fstat(dso->data.fd, &st) < 0) {
Signature · 1 line
2.1.0
author maintainer
#11 lore raw

PATCH 11/37 perf tools: Get rid of dso__data_fd() from dso__data_size()

In reply to Arnaldo Carvalho de Melo

From: Namhyung Kim <[email protected]>

It seems that the dso__data_fd() was needed to find a binary type since open in data_file_size() alone used to fail.

But as it can open the dso fine now, the dso__data_fd() can go away.

---
 tools/perf/util/dso.c | 6 ------
 1 file changed, 6 deletions(-)
tools/perf/util/dso.c +0 -6
index 516e0c25ea16..e95e850dd832 100644
@@ -745,12 +745,6 @@ out:
  */
 off_t dso__data_size(struct dso *dso, struct machine *machine)
 {
-	int fd;
-
-	fd = dso__data_fd(dso, machine);
-	if (fd < 0)
-		return fd;
-
 	if (data_file_size(dso, machine))
 		return -1;
 
Signature · 1 line
2.1.0
author maintainer
#12 lore raw

PATCH 12/37 perf tools: Add dso__data_get/put_fd()

In reply to Arnaldo Carvalho de Melo

From: Namhyung Kim <[email protected]>

Using dso__data_fd() in multi-thread environment is not safe since returned fd can be closed and/or reused anytime.

So convert it to the dso__data_get/put_fd() pair to protect the access with lock.

The original dso__data_fd() is deprecated and kept only for testing.

---
 tools/perf/tests/dso-data.c        | 11 +++++++++++
 tools/perf/util/dso.c              | 31 ++++++++++++++++++++++---------
 tools/perf/util/dso.h              | 13 +++++++++----
 tools/perf/util/unwind-libunwind.c | 11 ++++++++---
 4 files changed, 50 insertions(+), 16 deletions(-)
tools/perf/tests/dso-data.c +11 -0
index 513e5febbe5a..3e41c61bd861 100644
@@ -99,6 +99,17 @@ struct test_data_offset offsets[] = {
 	},
 };
 
+/* move it from util/dso.c for compatibility */
+static int dso__data_fd(struct dso *dso, struct machine *machine)
+{
+	int fd = dso__data_get_fd(dso, machine);
+
+	if (fd >= 0)
+		dso__data_put_fd(dso);
+
+	return fd;
+}
+
 int test__dso_data(void)
 {
 	struct machine machine;
tools/perf/util/dso.c +22 -9
index e95e850dd832..7e11a700303f 100644
@@ -473,25 +473,35 @@ out:
 }
 
 /**
- * dso__data_fd - Get dso's data file descriptor
+ * dso__data_get_fd - Get dso's data file descriptor
  * @dso: dso object
  * @machine: machine object
  *
  * External interface to find dso's file, open it and
- * returns file descriptor.
+ * returns file descriptor.  It should be paired with
+ * dso__data_put_fd() if it returns non-negative value.
  */
-int dso__data_fd(struct dso *dso, struct machine *machine)
+int dso__data_get_fd(struct dso *dso, struct machine *machine)
 {
 	if (dso->data.status == DSO_DATA_STATUS_ERROR)
 		return -1;
 
-	pthread_mutex_lock(&dso__data_open_lock);
+	if (pthread_mutex_lock(&dso__data_open_lock) < 0)
+		return -1;
+
 	try_to_open_dso(dso, machine);
-	pthread_mutex_unlock(&dso__data_open_lock);
+
+	if (dso->data.fd < 0)
+		pthread_mutex_unlock(&dso__data_open_lock);
 
 	return dso->data.fd;
 }
 
+void dso__data_put_fd(struct dso *dso __maybe_unused)
+{
+	pthread_mutex_unlock(&dso__data_open_lock);
+}
+
 bool dso__data_status_seen(struct dso *dso, enum dso_data_status_seen by)
 {
 	u32 flag = 1 << by;
@@ -1199,12 +1209,15 @@ size_t dso__fprintf(struct dso *dso, enum map_type type, FILE *fp)
 enum dso_type dso__type(struct dso *dso, struct machine *machine)
 {
 	int fd;
+	enum dso_type type = DSO__TYPE_UNKNOWN;
 
-	fd = dso__data_fd(dso, machine);
-	if (fd < 0)
-		return DSO__TYPE_UNKNOWN;
+	fd = dso__data_get_fd(dso, machine);
+	if (fd >= 0) {
+		type = dso__type_fd(fd);
+		dso__data_put_fd(dso);
+	}
 
-	return dso__type_fd(fd);
+	return type;
 }
 
 int dso__strerror_load(struct dso *dso, char *buf, size_t buflen)
tools/perf/util/dso.h +9 -4
index b26ec3ab1336..bcec06ad73a2 100644
@@ -240,7 +240,8 @@ int __kmod_path__parse(struct kmod_path *m, const char *path,
 
 /*
  * The dso__data_* external interface provides following functions:
- *   dso__data_fd
+ *   dso__data_get_fd
+ *   dso__data_put_fd
  *   dso__data_close
  *   dso__data_size
  *   dso__data_read_offset
@@ -257,8 +258,11 @@ int __kmod_path__parse(struct kmod_path *m, const char *path,
  * The current usage of the dso__data_* interface is as follows:
  *
  * Get DSO's fd:
- *   int fd = dso__data_fd(dso, machine);
- *   USE 'fd' SOMEHOW
+ *   int fd = dso__data_get_fd(dso, machine);
+ *   if (fd >= 0) {
+ *       USE 'fd' SOMEHOW
+ *       dso__data_put_fd(dso);
+ *   }
  *
  * Read DSO's data:
  *   n = dso__data_read_offset(dso_0, &machine, 0, buf, BUFSIZE);
@@ -277,7 +281,8 @@ int __kmod_path__parse(struct kmod_path *m, const char *path,
  *
  * TODO
 */
-int dso__data_fd(struct dso *dso, struct machine *machine);
+int dso__data_get_fd(struct dso *dso, struct machine *machine);
+void dso__data_put_fd(struct dso *dso __maybe_unused);
 void dso__data_close(struct dso *dso);
 
 off_t dso__data_size(struct dso *dso, struct machine *machine);
tools/perf/util/unwind-libunwind.c +8 -3
index 7b09a443a280..f079b63f0b7f 100644
@@ -269,13 +269,14 @@ static int read_unwind_spec_eh_frame(struct dso *dso, struct machine *machine,
 	u64 offset = dso->data.eh_frame_hdr_offset;
 
 	if (offset == 0) {
-		fd = dso__data_fd(dso, machine);
+		fd = dso__data_get_fd(dso, machine);
 		if (fd < 0)
 			return -EINVAL;
 
 		/* Check the .eh_frame section for unwinding info */
 		offset = elf_section_offset(fd, ".eh_frame_hdr");
 		dso->data.eh_frame_hdr_offset = offset;
+		dso__data_put_fd(dso);
 	}
 
 	if (offset)
@@ -294,13 +295,14 @@ static int read_unwind_spec_debug_frame(struct dso *dso,
 	u64 ofs = dso->data.debug_frame_offset;
 
 	if (ofs == 0) {
-		fd = dso__data_fd(dso, machine);
+		fd = dso__data_get_fd(dso, machine);
 		if (fd < 0)
 			return -EINVAL;
 
 		/* Check the .debug_frame section for unwinding info */
 		ofs = elf_section_offset(fd, ".debug_frame");
 		dso->data.debug_frame_offset = ofs;
+		dso__data_put_fd(dso);
 	}
 
 	*offset = ofs;
@@ -353,10 +355,13 @@ find_proc_info(unw_addr_space_t as, unw_word_t ip, unw_proc_info_t *pi,
 #ifndef NO_LIBUNWIND_DEBUG_FRAME
 	/* Check the .debug_frame section for unwinding info */
 	if (!read_unwind_spec_debug_frame(map->dso, ui->machine, &segbase)) {
-		int fd = dso__data_fd(map->dso, ui->machine);
+		int fd = dso__data_get_fd(map->dso, ui->machine);
 		int is_exec = elf_is_exec(fd, map->dso->name);
 		unw_word_t base = is_exec ? 0 : map->start;
 
+		if (fd >= 0)
+			dso__data_put_fd(dso);
+
 		memset(&di, 0, sizeof(di));
 		if (dwarf_find_debug_frame(0, &di, ip, base, map->dso->name,
 					   map->start, map->end))
Signature · 1 line
2.1.0
author maintainer
#13 lore raw

PATCH 13/37 perf tools: Rename maps__next

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

It really is a 'struct map' method, and since we're introducing a new 'struct maps' class, fix it to avoid confusion.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/map.c | 2 +-
 tools/perf/util/map.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
tools/perf/util/map.c +1 -1
index 2d20c5ff8653..09a62731e035 100644
@@ -775,7 +775,7 @@ struct map *maps__first(struct rb_root *maps)
 	return NULL;
 }
 
-struct map *maps__next(struct map *map)
+struct map *map__next(struct map *map)
 {
 	struct rb_node *next = rb_next(&map->rb_node);
 
tools/perf/util/map.h +2 -2
index 7f39217d29bf..aba9569165ea 100644
@@ -166,7 +166,7 @@ void maps__insert(struct rb_root *maps, struct map *map);
 void maps__remove(struct rb_root *maps, struct map *map);
 struct map *maps__find(struct rb_root *maps, u64 addr);
 struct map *maps__first(struct rb_root *maps);
-struct map *maps__next(struct map *map);
+struct map *map__next(struct map *map);
 void map_groups__init(struct map_groups *mg, struct machine *machine);
 void map_groups__exit(struct map_groups *mg);
 int map_groups__clone(struct map_groups *mg,
@@ -201,7 +201,7 @@ static inline struct map *map_groups__first(struct map_groups *mg,
 
 static inline struct map *map_groups__next(struct map *map)
 {
-	return maps__next(map);
+	return map__next(map);
 }
 
 struct symbol *map_groups__find_symbol(struct map_groups *mg,
Signature · 1 line
2.1.0
author maintainer
#14 lore raw

PATCH 14/37 perf tools: Remove redundant initialization of thread linkage members

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

A thread moves from a rb tree to a list, but can't be on both, because those linkage members are in a union. This is leftover from when I was debugging thread refcounting and had nuked that union.

It is harmless duplication, as RB_CLEAR_NODE() does again what INIT_LIST_HEAD does.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/thread.c | 2 --
 1 file changed, 2 deletions(-)
tools/perf/util/thread.c +0 -2
index 16c28a37a9e4..28c4b746baa1 100644
@@ -54,7 +54,6 @@ struct thread *thread__new(pid_t pid, pid_t tid)
 
 		list_add(&comm->list, &thread->comm_list);
 		atomic_set(&thread->refcnt, 0);
-		INIT_LIST_HEAD(&thread->node);
 		RB_CLEAR_NODE(&thread->rb_node);
 	}
 
@@ -70,7 +69,6 @@ void thread__delete(struct thread *thread)
 	struct comm *comm, *tmp;
 
 	BUG_ON(!RB_EMPTY_NODE(&thread->rb_node));
-	BUG_ON(!list_empty(&thread->node));
 
 	thread_stack__free(thread);
 
Signature · 1 line
2.1.0
author maintainer
#15 lore raw

PATCH 15/37 perf tools: Nuke unused map_groups__flush()

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

Since:

9fdbf671ba7e "perf tools: do not flush maps on COMM for perf report"

We have no users of this function, nuke it.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Luigi Semenzato <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/map.c | 22 ----------------------
 tools/perf/util/map.h |  2 --
 2 files changed, 24 deletions(-)
tools/perf/util/map.c +0 -22
index 09a62731e035..c1bfd0a12a94 100644
@@ -498,28 +498,6 @@ void map_groups__put(struct map_groups *mg)
 		map_groups__delete(mg);
 }
 
-void map_groups__flush(struct map_groups *mg)
-{
-	int type;
-
-	for (type = 0; type < MAP__NR_TYPES; type++) {
-		struct rb_root *root = &mg->maps[type];
-		struct rb_node *next = rb_first(root);
-
-		while (next) {
-			struct map *pos = rb_entry(next, struct map, rb_node);
-			next = rb_next(&pos->rb_node);
-			rb_erase(&pos->rb_node, root);
-			/*
-			 * We may have references to this map, for
-			 * instance in some hist_entry instances, so
-			 * just move them to a separate list.
-			 */
-			list_add_tail(&pos->node, &mg->removed_maps[pos->type]);
-		}
-	}
-}
-
 struct symbol *map_groups__find_symbol(struct map_groups *mg,
 				       enum map_type type, u64 addr,
 				       struct map **mapp,
tools/perf/util/map.h +0 -2
index aba9569165ea..f2b27566d986 100644
@@ -233,6 +233,4 @@ int map_groups__fixup_overlappings(struct map_groups *mg, struct map *map,
 struct map *map_groups__find_by_name(struct map_groups *mg,
 				     enum map_type type, const char *name);
 
-void map_groups__flush(struct map_groups *mg);
-
 #endif /* __PERF_MAP_H */
Signature · 1 line
2.1.0
author maintainer
#16 lore raw

PATCH 16/37 perf tools: Import rb_erase_init from block/ in the kernel sources

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

I was assuming rb_erase() was setting things up like list_del_init, but the fact that thread__delete() was being sucessfull is because the last thing before deleting is to remove the thread from the machine->dead_threads list, using list_del_init(), that has the same effect as using rb_erase_init()...

Introduce this function so that we can use it when removing objects from rb_trees.

Then we will be able to BUG_ON(still on a list) in destructors.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/include/linux/rbtree.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
tools/perf/util/include/linux/rbtree.h +14 -0
index 2a030c5af3aa..f06d89f0b867 100644
@@ -1,2 +1,16 @@
+#ifndef __TOOLS_LINUX_PERF_RBTREE_H
+#define __TOOLS_LINUX_PERF_RBTREE_H
 #include <stdbool.h>
 #include "../../../../include/linux/rbtree.h"
+
+/*
+ * Handy for checking that we are not deleting an entry that is
+ * already in a list, found in block/{blk-throttle,cfq-iosched}.c,
+ * probably should be moved to lib/rbtree.c...
+ */
+static inline void rb_erase_init(struct rb_node *n, struct rb_root *root)
+{
+	rb_erase(n, root);
+	RB_CLEAR_NODE(n);
+}
+#endif /* __TOOLS_LINUX_PERF_RBTREE_H */
Signature · 1 line
2.1.0
author maintainer
#17 lore raw

PATCH 17/37 perf machine: Mark removed threads as such

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

We use:

  BUG_ON(!RB_EMPTY_NODE(&thread->rb_node));

in the thread destructor as a debugging check to find out about possibly still referenced thread instances being deleted, to do that we need to make sure we use RB_CLEAR_NODE() right after rb_erase(), i.e. that we use the newly introduced rb_erase_init(), that works just like list_del_init().

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/machine.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/machine.c +2 -2
index 7ec3188d3cb3..6bf845758ae3 100644
@@ -400,7 +400,7 @@ static struct thread *____machine__findnew_thread(struct machine *machine,
 		 * leader and that would screwed the rb tree.
 		 */
 		if (thread__init_map_groups(th, machine)) {
-			rb_erase(&th->rb_node, &machine->threads);
+			rb_erase_init(&th->rb_node, &machine->threads);
 			RB_CLEAR_NODE(&th->rb_node);
 			thread__delete(th);
 			return NULL;
@@ -1314,7 +1314,7 @@ static void __machine__remove_thread(struct machine *machine, struct thread *th,
 	BUG_ON(atomic_read(&th->refcnt) == 0);
 	if (lock)
 		pthread_rwlock_wrlock(&machine->threads_lock);
-	rb_erase(&th->rb_node, &machine->threads);
+	rb_erase_init(&th->rb_node, &machine->threads);
 	RB_CLEAR_NODE(&th->rb_node);
 	/*
 	 * Move it first to the dead_threads list, then drop the reference,
Signature · 1 line
2.1.0
author maintainer
#18 lore raw

PATCH 18/37 perf tools: Leave DSO destruction to the map destruction

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

As the way DSOs are created are normally via dsos__findnew, so that we don't have to load the same dso multiple times for multiple maps (think about /lib64/libc.so.6), so they may be shared and dso__delete() should be left to be done as part of the map destruction process.

This will all be properly solved by reference counting struct dso, which will be done soon.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/probe-event.c | 3 ---
 1 file changed, 3 deletions(-)
tools/perf/util/probe-event.c +0 -3
index 1faa1e67398b..db6021834e8f 100644
@@ -195,7 +195,6 @@ static void put_target_map(struct map *map, bool user)
 {
 	if (map && user) {
 		/* Only the user map needs to be released */
-		dso__delete(map->dso);
 		map__delete(map);
 	}
 }
@@ -1791,7 +1790,6 @@ static int find_perf_probe_point_from_map(struct probe_trace_point *tp,
 
 out:
 	if (map && !is_kprobe) {
-		dso__delete(map->dso);
 		map__delete(map);
 	}
 
@@ -2884,7 +2882,6 @@ int show_available_funcs(const char *target, struct strfilter *_filter,
 	dso__fprintf_symbols_by_name(map->dso, map->type, stdout);
 end:
 	if (user) {
-		dso__delete(map->dso);
 		map__delete(map);
 	}
 	exit_symbol_maps();
Signature · 1 line
2.1.0
author maintainer
#19 lore raw

PATCH 19/37 perf tools: Use maps__first()/map__next()

In reply to Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <[email protected]>

In a few more remaining places, for consistency.

Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Don Zickus <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/tests/vmlinux-kallsyms.c | 34 +++++++++++++++++-----------------
 tools/perf/util/event.c             |  7 +++----
 tools/perf/util/map.c               |  7 ++++---
 tools/perf/util/probe-event.c       |  6 +++---
 tools/perf/util/symbol.c            | 23 ++++++++++-------------
 5 files changed, 37 insertions(+), 40 deletions(-)
tools/perf/tests/vmlinux-kallsyms.c +17 -17
index 3d9088003a5b..94ac6924df65 100644
@@ -23,9 +23,10 @@ int test__vmlinux_matches_kallsyms(void)
 	int err = -1;
 	struct rb_node *nd;
 	struct symbol *sym;
-	struct map *kallsyms_map, *vmlinux_map;
+	struct map *kallsyms_map, *vmlinux_map, *map;
 	struct machine kallsyms, vmlinux;
 	enum map_type type = MAP__FUNCTION;
+	struct rb_root *maps = &vmlinux.kmaps.maps[type];
 	u64 mem_start, mem_end;
 
 	/*
@@ -184,8 +185,8 @@ detour:
 
 	pr_info("Maps only in vmlinux:\n");
 
-	for (nd = rb_first(&vmlinux.kmaps.maps[type]); nd; nd = rb_next(nd)) {
-		struct map *pos = rb_entry(nd, struct map, rb_node), *pair;
+	for (map = maps__first(maps); map; map = map__next(map)) {
+		struct map *
 		/*
 		 * If it is the kernel, kallsyms is always "[kernel.kallsyms]", while
 		 * the kernel will have the path for the vmlinux file being used,
@@ -193,22 +194,22 @@ detour:
 		 * both cases.
 		 */
 		pair = map_groups__find_by_name(&kallsyms.kmaps, type,
-						(pos->dso->kernel ?
-							pos->dso->short_name :
-							pos->dso->name));
+						(map->dso->kernel ?
+							map->dso->short_name :
+							map->dso->name));
 		if (pair)
 			pair->priv = 1;
 		else
-			map__fprintf(pos, stderr);
+			map__fprintf(map, stderr);
 	}
 
 	pr_info("Maps in vmlinux with a different name in kallsyms:\n");
 
-	for (nd = rb_first(&vmlinux.kmaps.maps[type]); nd; nd = rb_next(nd)) {
-		struct map *pos = rb_entry(nd, struct map, rb_node), *pair;
+	for (map = maps__first(maps); map; map = map__next(map)) {
+		struct map *pair;
 
-		mem_start = vmlinux_map->unmap_ip(vmlinux_map, pos->start);
-		mem_end = vmlinux_map->unmap_ip(vmlinux_map, pos->end);
+		mem_start = vmlinux_map->unmap_ip(vmlinux_map, map->start);
+		mem_end = vmlinux_map->unmap_ip(vmlinux_map, map->end);
 
 		pair = map_groups__find(&kallsyms.kmaps, type, mem_start);
 		if (pair == NULL || pair->priv)
@@ -217,7 +218,7 @@ detour:
 		if (pair->start == mem_start) {
 			pair->priv = 1;
 			pr_info(" %" PRIx64 "-%" PRIx64 " %" PRIx64 " %s in kallsyms as",
-				pos->start, pos->end, pos->pgoff, pos->dso->name);
+				map->start, map->end, map->pgoff, map->dso->name);
 			if (mem_end != pair->end)
 				pr_info(":\n*%" PRIx64 "-%" PRIx64 " %" PRIx64,
 					pair->start, pair->end, pair->pgoff);
@@ -228,12 +229,11 @@ detour:
 
 	pr_info("Maps only in kallsyms:\n");
 
-	for (nd = rb_first(&kallsyms.kmaps.maps[type]);
-	     nd; nd = rb_next(nd)) {
-		struct map *pos = rb_entry(nd, struct map, rb_node);
+	maps = &kallsyms.kmaps.maps[type];
 
-		if (!pos->priv)
-			map__fprintf(pos, stderr);
+	for (map = maps__first(maps); map; map = map__next(map)) {
+		if (!map->priv)
+			map__fprintf(map, stderr);
 	}
 out:
 	machine__exit(&kallsyms);
tools/perf/util/event.c +3 -4
index a513a51f7330..9d3bba175423 100644
@@ -329,8 +329,9 @@ int perf_event__synthesize_modules(struct perf_tool *tool,
 				   struct machine *machine)
 {
 	int rc = 0;
-	struct rb_node *nd;
+	struct map *pos;
 	struct map_groups *kmaps = &machine->kmaps;
+	struct rb_root *maps = &kmaps->maps[MAP__FUNCTION];
 	union perf_event *event = zalloc((sizeof(event->mmap) +
 					  machine->id_hdr_size));
 	if (event == NULL) {
@@ -350,10 +351,8 @@ int perf_event__synthesize_modules(struct perf_tool *tool,
 	else
 		event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
 
-	for (nd = rb_first(&kmaps->maps[MAP__FUNCTION]);
-	     nd; nd = rb_next(nd)) {
+	for (pos = maps__first(maps); pos; pos = map__next(pos)) {
 		size_t size;
-		struct map *pos = rb_entry(nd, struct map, rb_node);
 
 		if (pos->dso->kernel)
 			continue;
tools/perf/util/map.c +4 -3
index c1bfd0a12a94..898ab92a98dd 100644
@@ -688,9 +688,10 @@ move_map:
 int map_groups__clone(struct map_groups *mg,
 		      struct map_groups *parent, enum map_type type)
 {
-	struct rb_node *nd;
-	for (nd = rb_first(&parent->maps[type]); nd; nd = rb_next(nd)) {
-		struct map *map = rb_entry(nd, struct map, rb_node);
+	struct map *map;
+	struct rb_root *maps = &parent->maps[type];
+
+	for (map = maps__first(maps); map; map = map__next(map)) {
 		struct map *new = map__clone(map);
 		if (new == NULL)
 			return -ENOMEM;
tools/perf/util/probe-event.c +3 -3
index db6021834e8f..092256516262 100644
@@ -162,8 +162,9 @@ static u64 kernel_get_symbol_address_by_name(const char *name, bool reloc)
 
 static struct map *kernel_get_module_map(const char *module)
 {
-	struct rb_node *nd;
 	struct map_groups *grp = &host_machine->kmaps;
+	struct rb_root *maps = &grp->maps[MAP__FUNCTION];
+	struct map *pos;
 
 	/* A file path -- this is an offline module */
 	if (module && strchr(module, '/'))
@@ -172,8 +173,7 @@ static struct map *kernel_get_module_map(const char *module)
 	if (!module)
 		module = "kernel";
 
-	for (nd = rb_first(&grp->maps[MAP__FUNCTION]); nd; nd = rb_next(nd)) {
-		struct map *pos = rb_entry(nd, struct map, rb_node);
+	for (pos = maps__first(maps); pos; pos = map__next(pos)) {
 		if (strncmp(pos->dso->short_name + 1, module,
 			    pos->dso->short_name_len - 2) == 0) {
 			return pos;
tools/perf/util/symbol.c +10 -13
index 82a31fd0fcf5..00b6b17e74a7 100644
@@ -202,18 +202,16 @@ void symbols__fixup_end(struct rb_root *symbols)
 
 void __map_groups__fixup_end(struct map_groups *mg, enum map_type type)
 {
-	struct map *prev, *curr;
-	struct rb_node *nd, *prevnd = rb_first(&mg->maps[type]);
+	struct rb_root *maps = &mg->maps[type];
+	struct map *next, *curr;
 
-	if (prevnd == NULL)
+	curr = maps__first(maps);
+	if (curr == NULL)
 		return;
 
-	curr = rb_entry(prevnd, struct map, rb_node);
-
-	for (nd = rb_next(prevnd); nd; nd = rb_next(nd)) {
-		prev = curr;
-		curr = rb_entry(nd, struct map, rb_node);
-		prev->end = curr->start;
+	for (next = map__next(curr); next; next = map__next(curr)) {
+		curr->end = next->start;
+		curr = next;
 	}
 
 	/*
@@ -1522,11 +1520,10 @@ out:
 struct map *map_groups__find_by_name(struct map_groups *mg,
 				     enum map_type type, const char *name)
 {
-	struct rb_node *nd;
-
-	for (nd = rb_first(&mg->maps[type]); nd; nd = rb_next(nd)) {
-		struct map *map = rb_entry(nd, struct map, rb_node);
+	struct rb_root *maps = &mg->maps[type];
+	struct map *map;
 
+	for (map = maps__first(maps); map; map = map__next(map)) {
 		if (map->dso && strcmp(map->dso->short_name, name) == 0)
 			return map;
 	}
Signature · 1 line
2.1.0
author maintainer
#20 lore raw

PATCH 20/37 perf tools: Assign default value for some pointers

In reply to Arnaldo Carvalho de Melo

From: Martin Liška <[email protected]>

Assign default value for pointers that are identified by the compiler as non-initialized.

---
 tools/perf/arch/common.c            | 2 +-
 tools/perf/util/symbol.c            | 2 +-
 tools/perf/util/trace-event-parse.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
tools/perf/arch/common.c +1 -1
index 49776f190abf..b7bb42c44694 100644
@@ -61,7 +61,7 @@ const char *const mips_triplets[] = {
 static bool lookup_path(char *name)
 {
 	bool found = false;
-	char *path, *tmp;
+	char *path, *tmp = NULL;
 	char buf[PATH_MAX];
 	char *env = getenv("PATH");
 
tools/perf/util/symbol.c +1 -1
index 00b6b17e74a7..b9e3eb581884 100644
@@ -398,7 +398,7 @@ static struct symbol *symbols__find_by_name(struct rb_root *symbols,
 					    const char *name)
 {
 	struct rb_node *n;
-	struct symbol_name_rb_node *s;
+	struct symbol_name_rb_node *s = NULL;
 
 	if (symbols == NULL)
 		return NULL;
tools/perf/util/trace-event-parse.c +1 -1
index 25d6c737be3e..d4957418657e 100644
@@ -173,7 +173,7 @@ void parse_ftrace_printk(struct pevent *pevent,
 	char *line;
 	char *next = NULL;
 	char *addr_str;
-	char *fmt;
+	char *fmt = NULL;
 
 	line = strtok_r(file, "\n", &next);
 	while (line) {
Signature · 1 line
2.1.0
author maintainer
#21 lore raw

PATCH 21/37 perf tools: Improve setting of gcc debug option

In reply to Arnaldo Carvalho de Melo

From: Martin Liska <[email protected]>

Correct debugging experience is given by passing -Og to compiler.

Do it in a way that supports older compilers

---
 tools/perf/config/Makefile      |  2 ++
 tools/perf/config/utilities.mak | 19 +++++++++++++++++++
 2 files changed, 21 insertions(+)
tools/perf/config/Makefile +2 -0
index e3b3724e73ff..317001c94660 100644
@@ -130,6 +130,8 @@ endif
 
 ifeq ($(DEBUG),0)
   CFLAGS += -O6
+else
+  CFLAGS += $(call cc-option,-Og,-O0)
 endif
 
 ifdef PARSER_DEBUG
tools/perf/config/utilities.mak +19 -0
index c16ce833079c..0ebef09c0842 100644
@@ -177,3 +177,22 @@ $(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
 endef
 _ge_attempt = $(if $(get-executable),$(get-executable),$(call _gea_err,$(2)))
 _gea_err  = $(if $(1),$(error Please set '$(1)' appropriately))
+
+# try-run
+# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
+# Exit code chooses option. "$$TMP" is can be used as temporary file and
+# is automatically cleaned up.
+try-run = $(shell set -e;		\
+	TMP="$(TMPOUT).$$$$.tmp";	\
+	TMPO="$(TMPOUT).$$$$.o";	\
+	if ($(1)) >/dev/null 2>&1;	\
+	then echo "$(2)";		\
+	else echo "$(3)";		\
+	fi;				\
+	rm -f "$$TMP" "$$TMPO")
+
+# cc-option
+# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
+
+cc-option = $(call try-run,\
+	$(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
Signature · 1 line
2.1.0
author maintainer
#22 lore raw

PATCH 22/37 perf sched: Add option to merge like comms to lat output

In reply to Arnaldo Carvalho de Melo

From: Josef Bacik <[email protected]>

Sometimes when debugging large multi-threaded applications it is helpful to collate all of the latency numbers into one bulk record to get an idea of what is going on.

This patch does this by merging any entries that belong to the same comm into one entry and then spits out those totals.

I've also slightly changed the output so you can see how many threads were merged in the processing. Here is the new default output format

-----------------------------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at |
-----------------------------------------------------------------------------------------------------------

  chrome:(23)          |  740.878 ms |     2612 | avg:    0.022 ms | max:    0.845 ms | max at: 7935.254223 s
  pulseaudio:1523      |   94.440 ms |      597 | avg:    0.027 ms | max:    0.110 ms | max at: 7934.668372 s
  threaded-ml:6042     |   72.554 ms |      386 | avg:    0.035 ms | max:    1.186 ms | max at: 7935.330911 s
  Chrome_IOThread:3832 |   52.388 ms |      456 | avg:    0.021 ms | max:    1.365 ms | max at: 7935.330602 s
  Chrome_ChildIOT:(7)  |   50.694 ms |      743 | avg:    0.021 ms | max:    1.448 ms | max at: 7935.256659 s
  Compositor:5510      |   30.012 ms |      192 | avg:    0.019 ms | max:    0.131 ms | max at: 7936.636815 s
  plugin_audio_th:6043 |   24.828 ms |      314 | avg:    0.018 ms | max:    0.143 ms | max at: 7936.205994 s
  CompositorTileW:(2)  |   14.099 ms |       45 | avg:    0.022 ms | max:    0.153 ms | max at: 7937.521800 s

the (#) after the task is the number of tasks merged, and then if there were no tasks merged it just shows the pid. Here is the same trace file with the -p option to print the per-pid latency numbers

-----------------------------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at |
-----------------------------------------------------------------------------------------------------------

  chrome:5500          |  386.872 ms |      387 | avg:    0.023 ms | max:    0.241 ms | max at: 7936.001694 s
  pulseaudio:1523      |   94.440 ms |      597 | avg:    0.027 ms | max:    0.110 ms | max at: 7934.668372 s
  threaded-ml:6042     |   72.554 ms |      386 | avg:    0.035 ms | max:    1.186 ms | max at: 7935.330911 s
  chrome:10226         |   69.710 ms |      251 | avg:    0.023 ms | max:    0.764 ms | max at: 7935.992305 s
  chrome:4267          |   64.551 ms |      418 | avg:    0.021 ms | max:    0.294 ms | max at: 7937.862427 s
  chrome:4827          |   62.268 ms |       54 | avg:    0.029 ms | max:    0.666 ms | max at: 7935.992813 s
  Chrome_IOThread:3832 |   52.388 ms |      456 | avg:    0.021 ms | max:    1.365 ms | max at: 7935.330602 s
  chrome:3776          |   46.150 ms |      349 | avg:    0.023 ms | max:    0.845 ms | max at: 7935.254223 s
---
 tools/perf/builtin-sched.c | 77 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 72 insertions(+), 5 deletions(-)
tools/perf/builtin-sched.c +72 -5
index 79273ecf92eb..33962612a5e9 100644
@@ -95,6 +95,7 @@ struct work_atoms {
 	u64			total_lat;
 	u64			nb_atoms;
 	u64			total_runtime;
+	int			num_merged;
 };
 
 typedef int (*sort_fn_t)(struct work_atoms *, struct work_atoms *);
@@ -168,9 +169,10 @@ struct perf_sched {
 	u64		 all_runtime;
 	u64		 all_count;
 	u64		 cpu_last_switched[MAX_CPUS];
-	struct rb_root	 atom_root, sorted_atom_root;
+	struct rb_root	 atom_root, sorted_atom_root, merged_atom_root;
 	struct list_head sort_list, cmp_pid;
 	bool force;
+	bool skip_merge;
 };
 
 static u64 get_nsecs(void)
@@ -1182,7 +1184,10 @@ static void output_lat_thread(struct perf_sched *sched, struct work_atoms *work_
 	sched->all_runtime += work_list->total_runtime;
 	sched->all_count   += work_list->nb_atoms;
 
-	ret = printf("  %s:%d ", thread__comm_str(work_list->thread), work_list->thread->tid);
+	if (work_list->num_merged > 1)
+		ret = printf("  %s:(%d) ", thread__comm_str(work_list->thread), work_list->num_merged);
+	else
+		ret = printf("  %s:%d ", thread__comm_str(work_list->thread), work_list->thread->tid);
 
 	for (i = 0; i < 24 - ret; i++)
 		printf(" ");
@@ -1302,17 +1307,22 @@ static int sort_dimension__add(const char *tok, struct list_head *list)
 static void perf_sched__sort_lat(struct perf_sched *sched)
 {
 	struct rb_node *node;
-
+	struct rb_root *root = &sched->atom_root;
+again:
 	for (;;) {
 		struct work_atoms *data;
-		node = rb_first(&sched->atom_root);
+		node = rb_first(root);
 		if (!node)
 			break;
 
-		rb_erase(node, &sched->atom_root);
+		rb_erase(node, root);
 		data = rb_entry(node, struct work_atoms, node);
 		__thread_latency_insert(&sched->sorted_atom_root, data, &sched->sort_list);
 	}
+	if (root == &sched->atom_root) {
+		root = &sched->merged_atom_root;
+		goto again;
+	}
 }
 
 static int process_sched_wakeup_event(struct perf_tool *tool,
@@ -1572,6 +1582,59 @@ static void print_bad_events(struct perf_sched *sched)
 	}
 }
 
+static void __merge_work_atoms(struct rb_root *root, struct work_atoms *data)
+{
+	struct rb_node **new = &(root->rb_node), *parent = NULL;
+	struct work_atoms *this;
+	const char *comm = thread__comm_str(data->thread), *this_comm;
+
+	while (*new) {
+		int cmp;
+
+		this = container_of(*new, struct work_atoms, node);
+		parent = *new;
+
+		this_comm = thread__comm_str(this->thread);
+		cmp = strcmp(comm, this_comm);
+		if (cmp > 0) {
+			new = &((*new)->rb_left);
+		} else if (cmp < 0) {
+			new = &((*new)->rb_right);
+		} else {
+			this->num_merged++;
+			this->total_runtime += data->total_runtime;
+			this->nb_atoms += data->nb_atoms;
+			this->total_lat += data->total_lat;
+			list_splice(&data->work_list, &this->work_list);
+			if (this->max_lat < data->max_lat) {
+				this->max_lat = data->max_lat;
+				this->max_lat_at = data->max_lat_at;
+			}
+			zfree(&data);
+			return;
+		}
+	}
+
+	data->num_merged++;
+	rb_link_node(&data->node, parent, new);
+	rb_insert_color(&data->node, root);
+}
+
+static void perf_sched__merge_lat(struct perf_sched *sched)
+{
+	struct work_atoms *data;
+	struct rb_node *node;
+
+	if (sched->skip_merge)
+		return;
+
+	while ((node = rb_first(&sched->atom_root))) {
+		rb_erase(node, &sched->atom_root);
+		data = rb_entry(node, struct work_atoms, node);
+		__merge_work_atoms(&sched->merged_atom_root, data);
+	}
+}
+
 static int perf_sched__lat(struct perf_sched *sched)
 {
 	struct rb_node *next;
@@ -1581,6 +1644,7 @@ static int perf_sched__lat(struct perf_sched *sched)
 	if (perf_sched__read_events(sched))
 		return -1;
 
+	perf_sched__merge_lat(sched);
 	perf_sched__sort_lat(sched);
 
 	printf("\n -----------------------------------------------------------------------------------------------------------------\n");
@@ -1732,6 +1796,7 @@ int cmd_sched(int argc, const char **argv, const char *prefix __maybe_unused)
 		.profile_cpu	      = -1,
 		.next_shortname1      = 'A',
 		.next_shortname2      = '0',
+		.skip_merge           = 0,
 	};
 	const struct option latency_options[] = {
 	OPT_STRING('s', "sort", &sched.sort_order, "key[,key2...]",
@@ -1742,6 +1807,8 @@ int cmd_sched(int argc, const char **argv, const char *prefix __maybe_unused)
 		    "CPU to profile on"),
 	OPT_BOOLEAN('D', "dump-raw-trace", &dump_trace,
 		    "dump raw trace in ASCII"),
+	OPT_BOOLEAN('p', "pids", &sched.skip_merge,
+		    "latency stats per pid instead of per comm"),
 	OPT_END()
 	};
 	const struct option replay_options[] = {
Signature · 1 line
2.1.0
author maintainer
#23 lore raw

PATCH 23/37 perf tools: Disallow PMU events intel_pt and intel_bts until there is support

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Disallow PMU events intel_pt and intel_bts until the tools support them.

By default any PMU is selectable as an event but until the tools have intel_pt and intel_bts support using them would result in no data being recorded without any indication as to why.

Before the change:

    $ perf record -e intel_bts// sleep 1
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.008 MB perf.data ]
    $ perf report --stdio
    Error:
    The perf.data file has no samples!

After the change:

    $ perf record -e intel_bts// sleep 1
    invalid or unsupported event: 'intel_bts//'
    Run 'perf list' for a list of valid events
---
 tools/perf/util/pmu.c | 4 ++++
 1 file changed, 4 insertions(+)
tools/perf/util/pmu.c +4 -0
index 244c66f89891..5d3ab7c8ceaf 100644
@@ -442,6 +442,10 @@ static struct perf_pmu *pmu_lookup(const char *name)
 	LIST_HEAD(aliases);
 	__u32 type;
 
+	/* No support for intel_bts or intel_pt so disallow them */
+	if (!strcmp(name, "intel_bts") || !strcmp(name, "intel_pt"))
+		return NULL;
+
 	/*
 	 * The pmu data we store & need consists of the pmu
 	 * type value and format definitions. Load both right
Signature · 1 line
2.1.0
author maintainer
#24 lore raw

PATCH 24/37 perf auxtrace: Add Intel PT as an AUX area tracing type

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Add the Intel Processor Trace type constant PERF_AUXTRACE_INTEL_PT.

---
 tools/perf/util/auxtrace.c | 1 +
 tools/perf/util/auxtrace.h | 1 +
 2 files changed, 2 insertions(+)
tools/perf/util/auxtrace.c +1 -0
index df66966cfde7..734c4d2a9208 100644
@@ -884,6 +884,7 @@ int perf_event__process_auxtrace_info(struct perf_tool *tool __maybe_unused,
 		fprintf(stdout, " type: %u\n", type);
 
 	switch (type) {
+	case PERF_AUXTRACE_INTEL_PT:
 	case PERF_AUXTRACE_UNKNOWN:
 	default:
 		return -EINVAL;
tools/perf/util/auxtrace.h +1 -0
index a171abbe7301..ed9874303b83 100644
@@ -39,6 +39,7 @@ struct events_stats;
 
 enum auxtrace_type {
 	PERF_AUXTRACE_UNKNOWN,
+	PERF_AUXTRACE_INTEL_PT,
 };
 
 enum itrace_period_type {
Signature · 1 line
2.1.0
author maintainer
#25 lore raw

PATCH 25/37 perf tools: Add Intel PT packet decoder

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Add support for decoding Intel Processor Trace packets.

---
 tools/perf/util/Build                              |   1 +
 tools/perf/util/intel-pt-decoder/Build             |   1 +
 .../util/intel-pt-decoder/intel-pt-pkt-decoder.c   | 400 +++++++++++++++++++++
 .../util/intel-pt-decoder/intel-pt-pkt-decoder.h   |  64 ++++
 4 files changed, 466 insertions(+)
 create mode 100644 tools/perf/util/intel-pt-decoder/Build
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.h
tools/perf/util/Build +1 -0
index 6966d0743bf7..a5b3672fc281 100644
@@ -75,6 +75,7 @@ libperf-$(CONFIG_X86) += tsc.o
 libperf-y += cloexec.o
 libperf-y += thread-stack.o
 libperf-$(CONFIG_AUXTRACE) += auxtrace.o
+libperf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
 
 libperf-$(CONFIG_LIBELF) += symbol-elf.o
 libperf-$(CONFIG_LIBELF) += probe-event.o
tools/perf/util/intel-pt-decoder/Build new file +1 -0
new file mode 100644
index 000000000000..9d67381a9bd3
@@ -0,0 +1 @@
+libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o
tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.c new file +400 -0

400 lines not on this page · raw message

tools/perf/util/intel-pt-decoder/intel-pt-pkt-decoder.h new file +64 -0

64 lines not on this page · raw message

Signature · 1 line
2.1.0
author maintainer
#26 lore raw

PATCH 26/37 perf tools: Add Intel PT instruction decoder

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Add support for decoding instructions for Intel Processor Trace. The kernel x86 instruction decoder is used for this.

---
 tools/build/Makefile.build                         |   2 +
 tools/perf/.gitignore                              |   2 +
 tools/perf/Makefile.perf                           |  12 +-
 tools/perf/util/intel-pt-decoder/Build             |  15 +-
 .../util/intel-pt-decoder/intel-pt-insn-decoder.c  | 246 +++++++++++++++++++++
 .../util/intel-pt-decoder/intel-pt-insn-decoder.h  |  65 ++++++
 6 files changed, 339 insertions(+), 3 deletions(-)
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h
tools/build/Makefile.build +2 -0
index 10df57237a66..7ad74e43f463 100644
@@ -57,6 +57,8 @@ quiet_cmd_cc_i_c = CPP      $@
 quiet_cmd_cc_s_c = AS       $@
       cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $<
 
+quiet_cmd_gen = GEN      $@
+
 # Link agregate command
 # If there's nothing to link, create empty $@ object.
 quiet_cmd_ld_multi = LD       $@
tools/perf/.gitignore +2 -0
index 812f904193e8..c88d5c56e81f 100644
@@ -28,3 +28,5 @@ config.mak.autogen
 *-flex.*
 *.pyc
 *.pyo
+util/intel-pt-decoder/inat-tables.c
+util/intel-pt-decoder/inat.c
tools/perf/Makefile.perf +10 -2
index 5816a3bb7e9f..3ae3a8e8ffa7 100644
@@ -76,6 +76,12 @@ include config/utilities.mak
 #
 # Define NO_AUXTRACE if you do not want AUX area tracing support
 
+# As per kernel Makefile, avoid funny character set dependencies
+unexport LC_ALL
+LC_COLLATE=C
+LC_NUMERIC=C
+export LC_COLLATE LC_NUMERIC
+
 ifeq ($(srctree),)
 srctree := $(patsubst %/,%,$(dir $(shell pwd)))
 srctree := $(patsubst %/,%,$(dir $(srctree)))
@@ -122,6 +128,7 @@ INSTALL = install
 FLEX    = flex
 BISON   = bison
 STRIP   = strip
+AWK     = awk
 
 LIB_DIR          = $(srctree)/tools/lib/api/
 TRACE_EVENT_DIR = $(srctree)/tools/lib/traceevent/
@@ -272,7 +279,7 @@ strip: $(PROGRAMS) $(OUTPUT)perf
 
 PERF_IN := $(OUTPUT)perf-in.o
 
-export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX
+export srctree OUTPUT RM CC LD AR CFLAGS V BISON FLEX AWK
 build := -f $(srctree)/tools/build/Makefile.build dir=. obj
 
 $(PERF_IN): $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h FORCE
@@ -536,7 +543,8 @@ clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean config-clean
 	$(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete
 	$(Q)$(RM) .config-detected
 	$(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf perf-read-vdso32 perf-read-vdsox32
-	$(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex*
+	$(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex* \
+		$(OUTPUT)util/intel-pt-decoder/inat.c $(OUTPUT)util/intel-pt-decoder/inat-tables.c
 	$(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean
 	$(python-clean)
 
tools/perf/util/intel-pt-decoder/Build +14 -1
index 9d67381a9bd3..f5f7f87eb718 100644
@@ -1 +1,14 @@
-libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o
+libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o
+
+inat_tables_script = ../../arch/x86/tools/gen-insn-attr-x86.awk
+inat_tables_maps = ../../arch/x86/lib/x86-opcode-map.txt
+
+$(OUTPUT)util/intel-pt-decoder/inat-tables.c: $(inat_tables_script) $(inat_tables_maps)
+	@$(call echo-cmd,gen)$(AWK) -f $(inat_tables_script) $(inat_tables_maps) > $@ || rm -f $@
+
+$(OUTPUT)util/intel-pt-decoder/inat.c:
+	@$(call echo-cmd,gen)cp ../../arch/x86/lib/inat.c $(OUTPUT)util/intel-pt-decoder/inat.c
+
+$(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: $(OUTPUT)util/intel-pt-decoder/inat.c $(OUTPUT)util/intel-pt-decoder/inat-tables.c
+
+CFLAGS_intel-pt-insn-decoder.o += -I../../arch/x86/include -I$(OUTPUT)util/intel-pt-decoder -I../../arch/x86/lib -Wno-override-init
tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c new file +246 -0

246 lines not on this page · raw message

tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h new file +65 -0

65 lines not on this page · raw message

Signature · 1 line
2.1.0
author maintainer
#27 lore raw

PATCH 27/37 perf tools: Add Intel PT log

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Add a facility to log Intel Processor Trace decoding. The log is intended for debugging purposes only.

The log file name is "intel_pt.log" and is opened in the current directory.

---
 tools/perf/util/intel-pt-decoder/Build          |   2 +-
 tools/perf/util/intel-pt-decoder/intel-pt-log.c | 155 ++++++++++++++++++++++++
 tools/perf/util/intel-pt-decoder/intel-pt-log.h |  52 ++++++++
 3 files changed, 208 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-log.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-log.h
tools/perf/util/intel-pt-decoder/Build +1 -1
index f5f7f87eb718..587321a67d95 100644
@@ -1,4 +1,4 @@
-libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o
+libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o intel-pt-log.o
 
 inat_tables_script = ../../arch/x86/tools/gen-insn-attr-x86.awk
 inat_tables_maps = ../../arch/x86/lib/x86-opcode-map.txt
tools/perf/util/intel-pt-decoder/intel-pt-log.c new file +155 -0

155 lines not on this page · raw message

tools/perf/util/intel-pt-decoder/intel-pt-log.h new file +52 -0

52 lines not on this page · raw message

Signature · 1 line
2.1.0
author maintainer
#28 lore raw

PATCH 28/37 perf tools: Add Intel PT decoder

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Add support for decoding an Intel Processor Trace.

---
 tools/perf/util/intel-pt-decoder/Build             |    2 +-
 .../perf/util/intel-pt-decoder/intel-pt-decoder.c  | 1758 ++++++++++++++++++++
 .../perf/util/intel-pt-decoder/intel-pt-decoder.h  |  102 ++
 3 files changed, 1861 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
 create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
tools/perf/util/intel-pt-decoder/Build +1 -1
index 587321a67d95..fa12eac57a22 100644
@@ -1,4 +1,4 @@
-libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o intel-pt-log.o
+libperf-$(CONFIG_AUXTRACE) += intel-pt-pkt-decoder.o intel-pt-insn-decoder.o intel-pt-log.o intel-pt-decoder.o
 
 inat_tables_script = ../../arch/x86/tools/gen-insn-attr-x86.awk
 inat_tables_maps = ../../arch/x86/lib/x86-opcode-map.txt
tools/perf/util/intel-pt-decoder/intel-pt-decoder.c new file +1758 -0

1,758 lines not on this page · raw message

tools/perf/util/intel-pt-decoder/intel-pt-decoder.h new file +102 -0

102 lines not on this page · raw message

Signature · 1 line
2.1.0
author maintainer
#29 lore raw

PATCH 29/37 perf tools: Add Intel PT support

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Add support for Intel Processor Trace.

---
 tools/perf/arch/x86/util/Build      |    2 +
 tools/perf/arch/x86/util/intel-pt.c |  752 ++++++++++++++
 tools/perf/util/Build               |    1 +
 tools/perf/util/intel-pt.c          | 1889 +++++++++++++++++++++++++++++++++++
 tools/perf/util/intel-pt.h          |   51 +
 5 files changed, 2695 insertions(+)
 create mode 100644 tools/perf/arch/x86/util/intel-pt.c
 create mode 100644 tools/perf/util/intel-pt.c
 create mode 100644 tools/perf/util/intel-pt.h
tools/perf/arch/x86/util/Build +2 -0
index cfbccc4e3187..139608878888 100644
@@ -6,3 +6,5 @@ libperf-$(CONFIG_DWARF) += dwarf-regs.o
 
 libperf-$(CONFIG_LIBUNWIND)          += unwind-libunwind.o
 libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
+
+libperf-$(CONFIG_AUXTRACE) += intel-pt.o
tools/perf/arch/x86/util/intel-pt.c new file +752 -0

752 lines not on this page · raw message

tools/perf/util/Build +1 -0
index a5b3672fc281..321f34bde7e2 100644
@@ -76,6 +76,7 @@ libperf-y += cloexec.o
 libperf-y += thread-stack.o
 libperf-$(CONFIG_AUXTRACE) += auxtrace.o
 libperf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
+libperf-$(CONFIG_AUXTRACE) += intel-pt.o
 
 libperf-$(CONFIG_LIBELF) += symbol-elf.o
 libperf-$(CONFIG_LIBELF) += probe-event.o
tools/perf/util/intel-pt.c new file +1889 -0

1,889 lines not on this page · raw message

tools/perf/util/intel-pt.h new file +51 -0

51 lines not on this page · raw message

Signature · 1 line
2.1.0
author maintainer
#30 lore raw

PATCH 30/37 perf tools: Take Intel PT into use

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

To record an AUX area, the weak function auxtrace_record__init() must be implemented.

Equally to decode an AUX area, the AUX area tracing type must be added to the perf_event__process_auxtrace_info() function.

This patch makes those two changes plus hooks up default config for the intel_pt PMU. Also some brief documentation is provided for using the tools with intel_pt.

---
 tools/perf/Documentation/intel-pt.txt | 467 ++++++++++++++++++++++++++++++++++
 tools/perf/arch/x86/util/Build        |   2 +
 tools/perf/arch/x86/util/auxtrace.c   |  38 +++
 tools/perf/arch/x86/util/pmu.c        |  15 ++
 tools/perf/util/auxtrace.c            |   5 +-
 tools/perf/util/pmu.c                 |   4 +-
 6 files changed, 528 insertions(+), 3 deletions(-)
 create mode 100644 tools/perf/Documentation/intel-pt.txt
 create mode 100644 tools/perf/arch/x86/util/auxtrace.c
 create mode 100644 tools/perf/arch/x86/util/pmu.c
tools/perf/Documentation/intel-pt.txt new file +467 -0
new file mode 100644
index 000000000000..f47ef1687262
@@ -0,0 +1,467 @@
+Intel Processor Trace
+=====================
+
+perf record
+===========
+
+new event
+---------
+
+The Intel PT kernel driver creates a new PMU for Intel PT.  PMU events are
+selected by providing the PMU name followed by the "config" separated by slashes.
+An enhancement has been made to allow default "config" e.g. the option
+
+	-e intel_pt//
+
+will use a default config value.  Currently that is the same as
+
+	-e intel_pt/tsc,noretcomp=0/
+
+which is the same as
+
+	-e intel_pt/tsc=1,noretcomp=0/
+
+The config terms are listed in /sys/devices/intel_pt/format.  They are bit
+fields within the config member of the struct perf_event_attr which is
+passed to the kernel by the perf_event_open system call.  They correspond to bit
+fields in the IA32_RTIT_CTL MSR.  Here is a list of them and their definitions:
+
+	$ for f in `ls /sys/devices/intel_pt/format`;do
+	> echo $f
+	> cat /sys/devices/intel_pt/format/$f
+	> done
+	noretcomp
+	config:11
+	tsc
+	config:10
+
+Note that the default config must be overridden for each term i.e.
+
+	-e intel_pt/noretcomp=0/
+
+is the same as:
+
+	-e intel_pt/tsc=1,noretcomp=0/
+
+So, to disable TSC packets use:
+
+	-e intel_pt/tsc=0/
+
+It is also possible to specify the config value explicitly:
+
+	-e intel_pt/config=0x400/
+
+Note that, as with all events, the event is suffixed with event modifiers:
+
+	u	userspace
+	k	kernel
+	h	hypervisor
+	G	guest
+	H	host
+	p	precise ip
+
+'h', 'G' and 'H' are for virtualization which is not supported by Intel PT.
+'p' is also not relevant to Intel PT.  So only options 'u' and 'k' are
+meaningful for Intel PT.
+
+perf_event_attr is displayed if the -vv option is used e.g.
+
+	------------------------------------------------------------
+	perf_event_attr:
+	type                             6
+	size                             112
+	config                           0x400
+	{ sample_period, sample_freq }   1
+	sample_type                      IP|TID|TIME|CPU|IDENTIFIER
+	read_format                      ID
+	disabled                         1
+	inherit                          1
+	exclude_kernel                   1
+	exclude_hv                       1
+	enable_on_exec                   1
+	sample_id_all                    1
+	------------------------------------------------------------
+	sys_perf_event_open: pid 31104  cpu 0  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 1  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 2  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 3  group_fd -1  flags 0x8
+	------------------------------------------------------------
+
+
+new snapshot option
+-------------------
+
+To select snapshot mode a new option has been added:
+
+	-S
+
+Optionally it can be followed by the snapshot size e.g.
+
+	-S0x100000
+
+The default snapshot size is the auxtrace mmap size.  If neither auxtrace mmap size
+nor snapshot size is specified, then the default is 4MiB for privileged users
+(or if /proc/sys/kernel/perf_event_paranoid < 0), 128KiB for unprivileged users.
+If an unprivileged user does not specify mmap pages, the mmap pages will be
+reduced as described in the 'new auxtrace mmap size option' section below.
+
+The snapshot size is displayed if the option -vv is used e.g.
+
+	Intel PT snapshot size: %zu
+
+
+new auxtrace mmap size option
+---------------------------
+
+Intel PT buffer size is specified by an addition to the -m option e.g.
+
+	-m,16
+
+selects a buffer size of 16 pages i.e. 64KiB.
+
+Note that the existing functionality of -m is unchanged.  The auxtrace mmap size
+is specified by the optional addition of a comma and the value.
+
+The default auxtrace mmap size for Intel PT is 4MiB/page_size for privileged users
+(or if /proc/sys/kernel/perf_event_paranoid < 0), 128KiB for unprivileged users.
+If an unprivileged user does not specify mmap pages, the mmap pages will be
+reduced from the default 512KiB/page_size to 256KiB/page_size, otherwise the
+user is likely to get an error as they exceed their mlock limit (Max locked
+memory as shown in /proc/self/limits).  Note that perf does not count the first
+512KiB (actually /proc/sys/kernel/perf_event_mlock_kb minus 1 page) per cpu
+against the mlock limit so an unprivileged user is allowed 512KiB per cpu plus
+their mlock limit (which defaults to 64KiB but is not multiplied by the number
+of cpus).
+
+In full-trace mode, powers of two are allowed for buffer size, with a minimum
+size of 2 pages.  In snapshot mode, it is the same but the minimum size is
+1 page.
+
+The mmap size and auxtrace mmap size are displayed if the -vv option is used e.g.
+
+	mmap length 528384
+	auxtrace mmap length 4198400
+
+
+Intel PT modes of operation
+---------------------------
+
+Intel PT can be used in 2 modes:
+	full-trace mode
+	snapshot mode
+
+Full-trace mode traces continuously e.g.
+
+	perf record -e intel_pt//u uname
+
+Snapshot mode captures the available data when a signal is sent e.g.
+
+	perf record -v -e intel_pt//u -S ./loopy 1000000000 &
+	[1] 11435
+	kill -USR2 11435
+	Recording AUX area tracing snapshot
+
+Note that the signal sent is SIGUSR2.
+Note that "Recording AUX area tracing snapshot" is displayed because the -v
+option is used.
+
+None of the 3 modes can be used together.
+
+
+Buffer handling
+---------------
+
+There may be buffer limitations (i.e. single ToPa entry) which means that actual
+buffer sizes are limited to powers of 2 up to 4MiB (MAX_ORDER).  In order to
+provide other sizes, and in particular an arbitrarily large size, multiple
+buffers are logically concatenated.  However an interrupt must be used to switch
+between buffers.  That has two potential problems:
+	a) the interrupt may not be handled in time so that the current buffer
+	becomes full and some trace data is lost.
+	b) the interrupts may slow the system and affect the performance
+	results.
+
+If trace data is lost, the driver sets 'truncated' in the PERF_RECORD_AUX event
+which the tools report as an error.
+
+In full-trace mode, the driver waits for data to be copied out before allowing
+the (logical) buffer to wrap-around.  If data is not copied out quickly enough,
+again 'truncated' is set in the PERF_RECORD_AUX event.  If the driver has to
+wait, the intel_pt event gets disabled.  Because it is difficult to know when
+that happens, perf tools always re-enable the intel_pt event after copying out
+data.
+
+
+Intel PT and build ids
+----------------------
+
+By default "perf record" post-processes the event stream to find all build ids
+for executables for all addresses sampled.  Deliberately, Intel PT is not
+decoded for that purpose (it would take too long).  Instead the build ids for
+all executables encountered (due to mmap, comm or task events) are included
+in the perf.data file.
+
+To see buildids included in the perf.data file use the command:
+
+	perf buildid-list
+
+If the perf.data file contains Intel PT data, that is the same as:
+
+	perf buildid-list --with-hits
+
+
+Snapshot mode and event disabling
+---------------------------------
+
+In order to make a snapshot, the intel_pt event is disabled using an IOCTL,
+namely PERF_EVENT_IOC_DISABLE.  However doing that can also disable the
+collection of side-band information.  In order to prevent that,  a dummy
+software event has been introduced that permits tracking events (like mmaps) to
+continue to be recorded while intel_pt is disabled.  That is important to ensure
+there is complete side-band information to allow the decoding of subsequent
+snapshots.
+
+A test has been created for that.  To find the test:
+
+	perf test list
+	...
+	23: Test using a dummy software event to keep tracking
+
+To run the test:
+
+	perf test 23
+	23: Test using a dummy software event to keep tracking     : Ok
+
+
+perf record modes (nothing new here)
+------------------------------------
+
+perf record essentially operates in one of three modes:
+	per thread
+	per cpu
+	workload only
+
+"per thread" mode is selected by -t or by --per-thread (with -p or -u or just a
+workload).
+"per cpu" is selected by -C or -a.
+"workload only" mode is selected by not using the other options but providing a
+command to run (i.e. the workload).
+
+In per-thread mode an exact list of threads is traced.  There is no inheritance.
+Each thread has its own event buffer.
+
+In per-cpu mode all processes (or processes from the selected cgroup i.e. -G
+option, or processes selected with -p or -u) are traced.  Each cpu has its own
+buffer. Inheritance is allowed.
+
+In workload-only mode, the workload is traced but with per-cpu buffers.
+Inheritance is allowed.  Note that you can now trace a workload in per-thread
+mode by using the --per-thread option.
+
+
+Privileged vs non-privileged users
+----------------------------------
+
+Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
+have memory limits imposed upon them.  That affects what buffer sizes they can
+have as outlined above.
+
+Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users are
+not permitted to use tracepoints which means there is insufficient side-band
+information to decode Intel PT in per-cpu mode, and potentially workload-only
+mode too if the workload creates new processes.
+
+Note also, that to use tracepoints, read-access to debugfs is required.  So if
+debugfs is not mounted or the user does not have read-access, it will again not
+be possible to decode Intel PT in per-cpu mode.
+
+
+sched_switch tracepoint
+-----------------------
+
+The sched_switch tracepoint is used to provide side-band data for Intel PT
+decoding.  sched_switch events are automatically added. e.g. the second event
+shown below
+
+	$ perf record -vv -e intel_pt//u uname
+	------------------------------------------------------------
+	perf_event_attr:
+	type                             6
+	size                             112
+	config                           0x400
+	{ sample_period, sample_freq }   1
+	sample_type                      IP|TID|TIME|CPU|IDENTIFIER
+	read_format                      ID
+	disabled                         1
+	inherit                          1
+	exclude_kernel                   1
+	exclude_hv                       1
+	enable_on_exec                   1
+	sample_id_all                    1
+	------------------------------------------------------------
+	sys_perf_event_open: pid 31104  cpu 0  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 1  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 2  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 3  group_fd -1  flags 0x8
+	------------------------------------------------------------
+	perf_event_attr:
+	type                             2
+	size                             112
+	config                           0x108
+	{ sample_period, sample_freq }   1
+	sample_type                      IP|TID|TIME|CPU|PERIOD|RAW|IDENTIFIER
+	read_format                      ID
+	inherit                          1
+	sample_id_all                    1
+	exclude_guest                    1
+	------------------------------------------------------------
+	sys_perf_event_open: pid -1  cpu 0  group_fd -1  flags 0x8
+	sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8
+	sys_perf_event_open: pid -1  cpu 2  group_fd -1  flags 0x8
+	sys_perf_event_open: pid -1  cpu 3  group_fd -1  flags 0x8
+	------------------------------------------------------------
+	perf_event_attr:
+	type                             1
+	size                             112
+	config                           0x9
+	{ sample_period, sample_freq }   1
+	sample_type                      IP|TID|TIME|IDENTIFIER
+	read_format                      ID
+	disabled                         1
+	inherit                          1
+	exclude_kernel                   1
+	exclude_hv                       1
+	mmap                             1
+	comm                             1
+	enable_on_exec                   1
+	task                             1
+	sample_id_all                    1
+	mmap2                            1
+	comm_exec                        1
+	------------------------------------------------------------
+	sys_perf_event_open: pid 31104  cpu 0  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 1  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 2  group_fd -1  flags 0x8
+	sys_perf_event_open: pid 31104  cpu 3  group_fd -1  flags 0x8
+	mmap size 528384B
+	AUX area mmap length 4194304
+	perf event ring buffer mmapped per cpu
+	Synthesizing auxtrace information
+	Linux
+	[ perf record: Woken up 1 times to write data ]
+	[ perf record: Captured and wrote 0.042 MB perf.data ]
+
+Note, the sched_switch event is only added if the user is permitted to use it
+and only in per-cpu mode.
+
+Note also, the sched_switch event is only added if TSC packets are requested.
+That is because, in the absence of timing information, the sched_switch events
+cannot be matched against the Intel PT trace.
+
+
+perf script
+===========
+
+By default, perf script will decode trace data found in the perf.data file.
+This can be further controlled by new option --itrace.
+
+
+New AUX area option
+----------------------------
+
+Having no option is the same as
+
+	--itrace
+
+which, in turn, is the same as
+
+	--itrace=ibxe
+
+The letters are:
+
+	i	synthesize "instructions" events
+	b	synthesize "branches" events
+	x	synthesize "transactions" events
+	c	synthesize branches events (calls only)
+	r	synthesize branches events (returns only)
+	e	synthesize tracing error events
+	d	create a debug log
+	g	synthesize a call chain (use with i or x)
+
+"Instructions" events look like they were recorded by "perf record -e
+instructions".
+
+"Branches" events look like they were recorded by "perf record -e branches". "c"
+and "r" can be combined to get calls and returns.
+
+"Transactions" events correspond to the start or end of transactions. The
+'flags' field can be used in perf script to determine whether the event is a
+tranasaction start, commit or abort.
+
+Error events are new.  They show where the decoder lost the trace.  Error events
+are quite important.  Users must know if what they are seeing is a complete
+picture or not.
+
+The "d" option will cause the creation of a file "intel_pt.log" containing all
+decoded packets and instructions.  Note that this option slows down the decoder
+and that the resulting file may be very large.
+
+In addition, the period of the "instructions" event can be specified. e.g.
+
+	--itrace=i10us
+
+sets the period to 10us i.e. one  instruction sample is synthesized for each 10
+microseconds of trace.  Alternatives to "us" are "ms" (milliseconds),
+"ns" (nanoseconds), "t" (TSC ticks) or "i" (instructions).
+
+"ms", "us" and "ns" are converted to TSC ticks.
+
+The timing information included with Intel PT does not give the time of every
+instruction.  Consequently, for the purpose of sampling, the decoder estimates
+the time since the last timing packet based on 1 tick per instruction.  The time
+on the sample is *not* adjusted and reflects the last known value of TSC.
+
+For Intel PT, the default period is 100us.
+
+Also the call chain size (default 16, max. 1024) for instructions or
+transactions events can be specified. e.g.
+
+	--itrace=ig32
+	--itrace=xg32
+
+To disable trace decoding entirely, use the option --no-itrace.
+
+
+dump option
+-----------
+
+perf script has an option (-D) to "dump" the events i.e. display the binary
+data.
+
+When -D is used, Intel PT packets are displayed.  The packet decoder does not
+pay attention to PSB packets, but just decodes the bytes - so the packets seen
+by the actual decoder may not be identical in places where the data is corrupt.
+One example of that would be when the buffer-switching interrupt has been too
+slow, and the buffer has been filled completely.  In that case, the last packet
+in the buffer might be truncated and immediately followed by a PSB as the trace
+continues in the next buffer.
+
+To disable the display of Intel PT packets, combine the -D option with
+--no-itrace.
+
+
+perf report
+===========
+
+By default, perf report will decode trace data found in the perf.data file.
+This can be further controlled by new option --itrace exactly the same as
+perf script, with the exception that the default is --itrace=ge.
+
+
+perf inject
+===========
+
+perf inject also accepts the --itrace option in which case tracing data is
+removed and replaced with the synthesized events. e.g.
+
+	perf inject --itrace -i perf.data -o perf.data.new
tools/perf/arch/x86/util/Build +2 -0
index 139608878888..a8be9f9d0462 100644
@@ -1,5 +1,6 @@
 libperf-y += header.o
 libperf-y += tsc.o
+libperf-y += pmu.o
 libperf-y += kvm-stat.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
@@ -7,4 +8,5 @@ libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_LIBUNWIND)          += unwind-libunwind.o
 libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
 
+libperf-$(CONFIG_AUXTRACE) += auxtrace.o
 libperf-$(CONFIG_AUXTRACE) += intel-pt.o
tools/perf/arch/x86/util/auxtrace.c new file +38 -0
new file mode 100644
index 000000000000..e7654b506312
@@ -0,0 +1,38 @@
+/*
+ * auxtrace.c: AUX area tracing support
+ * Copyright (c) 2013-2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include "../../util/header.h"
+#include "../../util/auxtrace.h"
+#include "../../util/intel-pt.h"
+
+struct auxtrace_record *auxtrace_record__init(struct perf_evlist *evlist __maybe_unused,
+					      int *err)
+{
+	char buffer[64];
+	int ret;
+
+	*err = 0;
+
+	ret = get_cpuid(buffer, sizeof(buffer));
+	if (ret) {
+		*err = ret;
+		return NULL;
+	}
+
+	if (!strncmp(buffer, "GenuineIntel,", 13))
+		return intel_pt_recording_init(err);
+
+	return NULL;
+}
tools/perf/arch/x86/util/pmu.c new file +15 -0
new file mode 100644
index 000000000000..fd11cc3ce780
@@ -0,0 +1,15 @@
+#include <string.h>
+
+#include <linux/perf_event.h>
+
+#include "../../util/intel-pt.h"
+#include "../../util/pmu.h"
+
+struct perf_event_attr *perf_pmu__get_default_config(struct perf_pmu *pmu __maybe_unused)
+{
+#ifdef HAVE_AUXTRACE_SUPPORT
+	if (!strcmp(pmu->name, INTEL_PT_PMU_NAME))
+		return intel_pt_pmu_default_config(pmu);
+#endif
+	return NULL;
+}
tools/perf/util/auxtrace.c +4 -1
index 734c4d2a9208..8b7d59a7cc9e 100644
@@ -47,6 +47,8 @@
 #include "debug.h"
 #include "parse-options.h"
 
+#include "intel-pt.h"
+
 int auxtrace_mmap__mmap(struct auxtrace_mmap *mm,
 			struct auxtrace_mmap_params *mp,
 			void *userpg, int fd)
@@ -876,7 +878,7 @@ static bool auxtrace__dont_decode(struct perf_session *session)
 
 int perf_event__process_auxtrace_info(struct perf_tool *tool __maybe_unused,
 				      union perf_event *event,
-				      struct perf_session *session __maybe_unused)
+				      struct perf_session *session)
 {
 	enum auxtrace_type type = event->auxtrace_info.type;
 
@@ -885,6 +887,7 @@ int perf_event__process_auxtrace_info(struct perf_tool *tool __maybe_unused,
 
 	switch (type) {
 	case PERF_AUXTRACE_INTEL_PT:
+		return intel_pt_process_auxtrace_info(event, session);
 	case PERF_AUXTRACE_UNKNOWN:
 	default:
 		return -EINVAL;
tools/perf/util/pmu.c +2 -2
index 5d3ab7c8ceaf..fddad8ba4b39 100644
@@ -442,8 +442,8 @@ static struct perf_pmu *pmu_lookup(const char *name)
 	LIST_HEAD(aliases);
 	__u32 type;
 
-	/* No support for intel_bts or intel_pt so disallow them */
-	if (!strcmp(name, "intel_bts") || !strcmp(name, "intel_pt"))
+	/* No support for intel_bts so disallow it */
+	if (!strcmp(name, "intel_bts"))
 		return NULL;
 
 	/*
Signature · 1 line
2.1.0
author maintainer
#31 lore raw

PATCH 31/37 perf tools: Allow auxtrace data alignment

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

Allow auxtrace data to be a multiple of something other than page size. That is needed for BTS where the buffer contains 24-byte records.

---
 tools/perf/util/auxtrace.c | 7 +++++++
 tools/perf/util/auxtrace.h | 1 +
 2 files changed, 8 insertions(+)
tools/perf/util/auxtrace.c +7 -0
index 8b7d59a7cc9e..2d57759d5b69 100644
@@ -1186,6 +1186,13 @@ static int __auxtrace_mmap__read(struct auxtrace_mmap *mm,
 		data2 = NULL;
 	}
 
+	if (itr->alignment) {
+		unsigned int unwanted = len1 % itr->alignment;
+
+		len1 -= unwanted;
+		size -= unwanted;
+	}
+
 	/* padding must be written by fn() e.g. record__process_auxtrace() */
 	padding = size & 7;
 	if (padding)
tools/perf/util/auxtrace.h +1 -0
index ed9874303b83..7d12f33a3a06 100644
@@ -304,6 +304,7 @@ struct auxtrace_record {
 				      const char *str);
 	u64 (*reference)(struct auxtrace_record *itr);
 	int (*read_finish)(struct auxtrace_record *itr, int idx);
+	unsigned int alignment;
 };
 
 #ifdef HAVE_AUXTRACE_SUPPORT
Signature · 1 line
2.1.0
author maintainer
#32 lore raw

PATCH 32/37 perf tools: Add Intel BTS support

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

---
 tools/perf/Documentation/intel-bts.txt |  69 +++
 tools/perf/arch/x86/util/Build         |   1 +
 tools/perf/arch/x86/util/auxtrace.c    |  49 +-
 tools/perf/arch/x86/util/intel-bts.c   | 458 +++++++++++++++++++
 tools/perf/arch/x86/util/pmu.c         |   3 +
 tools/perf/util/Build                  |   1 +
 tools/perf/util/auxtrace.c             |   3 +
 tools/perf/util/auxtrace.h             |   1 +
 tools/perf/util/intel-bts.c            | 793 +++++++++++++++++++++++++++++++++
 tools/perf/util/intel-bts.h            |  43 ++
 tools/perf/util/pmu.c                  |   4 -
 11 files changed, 1419 insertions(+), 6 deletions(-)
 create mode 100644 tools/perf/Documentation/intel-bts.txt
 create mode 100644 tools/perf/arch/x86/util/intel-bts.c
 create mode 100644 tools/perf/util/intel-bts.c
 create mode 100644 tools/perf/util/intel-bts.h
tools/perf/Documentation/intel-bts.txt new file +69 -0
new file mode 100644
index 000000000000..7a79d363454b
@@ -0,0 +1,69 @@
+Intel Branch Trace Store
+========================
+
+perf record
+===========
+
+new event
+---------
+
+The Intel BTS kernel driver creates a new PMU for Intel BTS.  The perf record
+option is:
+
+	-e intel_bts//
+
+Currently Intel BTS is limited to per-thread tracing so the --per-thread option
+is also needed.
+
+
+snapshot option
+---------------
+
+The snapshot option is the same as Intel PT (refer Intel PT documentation).
+
+
+auxtrace mmap size option
+-----------------------
+
+The mmap size option is the same as Intel PT (refer Intel PT documentation).
+
+
+perf script
+===========
+
+By default, perf script will decode trace data found in the perf.data file.
+This can be further controlled by option --itrace.  The --itrace option is
+the same as Intel PT (refer Intel PT documentation) except that neither
+"instructions" events nor "transactions" events (and consequently call
+chains) are supported.
+
+To disable trace decoding entirely, use the option --no-itrace.
+
+
+dump option
+-----------
+
+perf script has an option (-D) to "dump" the events i.e. display the binary
+data.
+
+When -D is used, Intel BTS packets are displayed.
+
+To disable the display of Intel BTS packets, combine the -D option with
+--no-itrace.
+
+
+perf report
+===========
+
+By default, perf report will decode trace data found in the perf.data file.
+This can be further controlled by new option --itrace exactly the same as
+perf script.
+
+
+perf inject
+===========
+
+perf inject also accepts the --itrace option in which case tracing data is
+removed and replaced with the synthesized events. e.g.
+
+	perf inject --itrace -i perf.data -o perf.data.new
tools/perf/arch/x86/util/Build +1 -0
index a8be9f9d0462..2c55e1b336c5 100644
@@ -10,3 +10,4 @@ libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
 
 libperf-$(CONFIG_AUXTRACE) += auxtrace.o
 libperf-$(CONFIG_AUXTRACE) += intel-pt.o
+libperf-$(CONFIG_AUXTRACE) += intel-bts.o
tools/perf/arch/x86/util/auxtrace.c +47 -2

65 lines not on this page · raw message

tools/perf/arch/x86/util/intel-bts.c new file +458 -0

458 lines not on this page · raw message

tools/perf/arch/x86/util/pmu.c +3 -0
index fd11cc3ce780..79fe07158d00 100644
@@ -3,6 +3,7 @@
 #include <linux/perf_event.h>
 
 #include "../../util/intel-pt.h"
+#include "../../util/intel-bts.h"
 #include "../../util/pmu.h"
 
 struct perf_event_attr *perf_pmu__get_default_config(struct perf_pmu *pmu __maybe_unused)
@@ -10,6 +11,8 @@ struct perf_event_attr *perf_pmu__get_default_config(struct perf_pmu *pmu __mayb
 #ifdef HAVE_AUXTRACE_SUPPORT
 	if (!strcmp(pmu->name, INTEL_PT_PMU_NAME))
 		return intel_pt_pmu_default_config(pmu);
+	if (!strcmp(pmu->name, INTEL_BTS_PMU_NAME))
+		pmu->selectable = true;
 #endif
 	return NULL;
 }
tools/perf/util/Build +1 -0
index 321f34bde7e2..2c261dc5d628 100644
@@ -77,6 +77,7 @@ libperf-y += thread-stack.o
 libperf-$(CONFIG_AUXTRACE) += auxtrace.o
 libperf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
 libperf-$(CONFIG_AUXTRACE) += intel-pt.o
+libperf-$(CONFIG_AUXTRACE) += intel-bts.o
 
 libperf-$(CONFIG_LIBELF) += symbol-elf.o
 libperf-$(CONFIG_LIBELF) += probe-event.o
tools/perf/util/auxtrace.c +3 -0
index 2d57759d5b69..aa93ab1ce63a 100644
@@ -48,6 +48,7 @@
 #include "parse-options.h"
 
 #include "intel-pt.h"
+#include "intel-bts.h"
 
 int auxtrace_mmap__mmap(struct auxtrace_mmap *mm,
 			struct auxtrace_mmap_params *mp,
@@ -888,6 +889,8 @@ int perf_event__process_auxtrace_info(struct perf_tool *tool __maybe_unused,
 	switch (type) {
 	case PERF_AUXTRACE_INTEL_PT:
 		return intel_pt_process_auxtrace_info(event, session);
+	case PERF_AUXTRACE_INTEL_BTS:
+		return intel_bts_process_auxtrace_info(event, session);
 	case PERF_AUXTRACE_UNKNOWN:
 	default:
 		return -EINVAL;
tools/perf/util/auxtrace.h +1 -0
index 7d12f33a3a06..bf72b77a588a 100644
@@ -40,6 +40,7 @@ struct events_stats;
 enum auxtrace_type {
 	PERF_AUXTRACE_UNKNOWN,
 	PERF_AUXTRACE_INTEL_PT,
+	PERF_AUXTRACE_INTEL_BTS,
 };
 
 enum itrace_period_type {
tools/perf/util/intel-bts.c new file +793 -0

793 lines not on this page · raw message

tools/perf/util/intel-bts.h new file +43 -0

43 lines not on this page · raw message

tools/perf/util/pmu.c +0 -4
index fddad8ba4b39..244c66f89891 100644
@@ -442,10 +442,6 @@ static struct perf_pmu *pmu_lookup(const char *name)
 	LIST_HEAD(aliases);
 	__u32 type;
 
-	/* No support for intel_bts so disallow it */
-	if (!strcmp(name, "intel_bts"))
-		return NULL;
-
 	/*
 	 * The pmu data we store & need consists of the pmu
 	 * type value and format definitions. Load both right
Signature · 1 line
2.1.0
author maintainer
#33 lore raw

PATCH 33/37 perf tools: Output sample flags and insn_len from intel_pt

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

intel_pt synthesizes samples. Fill in the new flags and insn_len members with instruction information.

---
 tools/perf/util/intel-pt.c | 4 ++++
 1 file changed, 4 insertions(+)
tools/perf/util/intel-pt.c +4 -0
index 6d66879e1e33..9c25bfadb4f3 100644
@@ -876,6 +876,8 @@ static int intel_pt_synth_branch_sample(struct intel_pt_queue *ptq)
 	sample.stream_id = ptq->pt->branches_id;
 	sample.period = 1;
 	sample.cpu = ptq->cpu;
+	sample.flags = ptq->flags;
+	sample.insn_len = ptq->insn_len;
 
 	if (pt->branches_filter && !(pt->branches_filter & ptq->flags))
 		return 0;
@@ -918,6 +920,8 @@ static int intel_pt_synth_instruction_sample(struct intel_pt_queue *ptq)
 	sample.stream_id = ptq->pt->instructions_id;
 	sample.period = ptq->pt->instructions_sample_period;
 	sample.cpu = ptq->cpu;
+	sample.flags = ptq->flags;
+	sample.insn_len = ptq->insn_len;
 
 	if (pt->synth_opts.callchain) {
 		thread_stack__sample(ptq->thread, ptq->chain,
Signature · 1 line
2.1.0
author maintainer
#34 lore raw

PATCH 34/37 perf tools: Output sample flags and insn_len from intel_bts

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

intel_bts synthesizes samples. Fill in the new flags and insn_len members with instruction information.

---
 tools/perf/util/intel-bts.c | 126 ++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 122 insertions(+), 4 deletions(-)
tools/perf/util/intel-bts.c +122 -4
index 48bcbd607ef7..b068860d4940 100644
@@ -30,6 +30,7 @@
 #include "debug.h"
 #include "tsc.h"
 #include "auxtrace.h"
+#include "intel-pt-decoder/intel-pt-insn-decoder.h"
 #include "intel-bts.h"
 
 #define MAX_TIMESTAMP (~0ULL)
@@ -58,6 +59,7 @@ struct intel_bts {
 	bool				cap_user_time_zero;
 	struct itrace_synth_opts	synth_opts;
 	bool				sample_branches;
+	u32				branches_filter;
 	u64				branches_sample_type;
 	u64				branches_id;
 	size_t				branches_event_size;
@@ -74,6 +76,8 @@ struct intel_bts_queue {
 	pid_t			tid;
 	int			cpu;
 	u64			time;
+	struct intel_pt_insn	intel_pt_insn;
+	u32			sample_flags;
 };
 
 struct branch {
@@ -281,6 +285,8 @@ static int intel_bts_synth_branch_sample(struct intel_bts_queue *btsq,
 	sample.stream_id = btsq->bts->branches_id;
 	sample.period = 1;
 	sample.cpu = btsq->cpu;
+	sample.flags = btsq->sample_flags;
+	sample.insn_len = btsq->intel_pt_insn.length;
 
 	if (bts->synth_opts.inject) {
 		event.sample.header.size = bts->branches_event_size;
@@ -300,11 +306,115 @@ static int intel_bts_synth_branch_sample(struct intel_bts_queue *btsq,
 	return ret;
 }
 
+static int intel_bts_get_next_insn(struct intel_bts_queue *btsq, u64 ip)
+{
+	struct machine *machine = btsq->bts->machine;
+	struct thread *thread;
+	struct addr_location al;
+	unsigned char buf[1024];
+	size_t bufsz;
+	ssize_t len;
+	int x86_64;
+	uint8_t cpumode;
+
+	bufsz = intel_pt_insn_max_size();
+
+	if (machine__kernel_ip(machine, ip))
+		cpumode = PERF_RECORD_MISC_KERNEL;
+	else
+		cpumode = PERF_RECORD_MISC_USER;
+
+	thread = machine__find_thread(machine, -1, btsq->tid);
+	if (!thread)
+		return -1;
+
+	thread__find_addr_map(thread, cpumode, MAP__FUNCTION, ip, &al);
+	if (!al.map || !al.map->dso)
+		return -1;
+
+	len = dso__data_read_addr(al.map->dso, al.map, machine, ip, buf, bufsz);
+	if (len <= 0)
+		return -1;
+
+	/* Load maps to ensure dso->is_64_bit has been updated */
+	map__load(al.map, machine->symbol_filter);
+
+	x86_64 = al.map->dso->is_64_bit;
+
+	if (intel_pt_get_insn(buf, len, x86_64, &btsq->intel_pt_insn))
+		return -1;
+
+	return 0;
+}
+
+static int intel_bts_synth_error(struct intel_bts *bts, int cpu, pid_t pid,
+				 pid_t tid, u64 ip)
+{
+	union perf_event event;
+	int err;
+
+	auxtrace_synth_error(&event.auxtrace_error, PERF_AUXTRACE_ERROR_ITRACE,
+			     INTEL_BTS_ERR_NOINSN, cpu, pid, tid, ip,
+			     "Failed to get instruction");
+
+	err = perf_session__deliver_synth_event(bts->session, &event, NULL);
+	if (err)
+		pr_err("Intel BTS: failed to deliver error event, error %d\n",
+		       err);
+
+	return err;
+}
+
+static int intel_bts_get_branch_type(struct intel_bts_queue *btsq,
+				     struct branch *branch)
+{
+	int err;
+
+	if (!branch->from) {
+		if (branch->to)
+			btsq->sample_flags = PERF_IP_FLAG_BRANCH |
+					     PERF_IP_FLAG_TRACE_BEGIN;
+		else
+			btsq->sample_flags = 0;
+		btsq->intel_pt_insn.length = 0;
+	} else if (!branch->to) {
+		btsq->sample_flags = PERF_IP_FLAG_BRANCH |
+				     PERF_IP_FLAG_TRACE_END;
+		btsq->intel_pt_insn.length = 0;
+	} else {
+		err = intel_bts_get_next_insn(btsq, branch->from);
+		if (err) {
+			btsq->sample_flags = 0;
+			btsq->intel_pt_insn.length = 0;
+			if (!btsq->bts->synth_opts.errors)
+				return 0;
+			err = intel_bts_synth_error(btsq->bts, btsq->cpu,
+						    btsq->pid, btsq->tid,
+						    branch->from);
+			return err;
+		}
+		btsq->sample_flags = intel_pt_insn_type(btsq->intel_pt_insn.op);
+		/* Check for an async branch into the kernel */
+		if (!machine__kernel_ip(btsq->bts->machine, branch->from) &&
+		    machine__kernel_ip(btsq->bts->machine, branch->to) &&
+		    btsq->sample_flags != (PERF_IP_FLAG_BRANCH |
+					   PERF_IP_FLAG_CALL |
+					   PERF_IP_FLAG_SYSCALLRET))
+			btsq->sample_flags = PERF_IP_FLAG_BRANCH |
+					     PERF_IP_FLAG_CALL |
+					     PERF_IP_FLAG_ASYNC |
+					     PERF_IP_FLAG_INTERRUPT;
+	}
+
+	return 0;
+}
+
 static int intel_bts_process_buffer(struct intel_bts_queue *btsq,
 				    struct auxtrace_buffer *buffer)
 {
 	struct branch *branch;
-	size_t sz;
+	size_t sz, bsz = sizeof(struct branch);
+	u32 filter = btsq->bts->branches_filter;
 	int err = 0;
 
 	if (buffer->use_data) {
@@ -318,14 +428,15 @@ static int intel_bts_process_buffer(struct intel_bts_queue *btsq,
 	if (!btsq->bts->sample_branches)
 		return 0;
 
-	while (sz > sizeof(struct branch)) {
+	for (; sz > bsz; branch += 1, sz -= bsz) {
 		if (!branch->from && !branch->to)
 			continue;
+		intel_bts_get_branch_type(btsq, branch);
+		if (filter && !(filter & btsq->sample_flags))
+			continue;
 		err = intel_bts_synth_branch_sample(btsq, branch);
 		if (err)
 			break;
-		branch += 1;
-		sz -= sizeof(struct branch);
 	}
 	return err;
 }
@@ -771,6 +882,13 @@ int intel_bts_process_auxtrace_info(union perf_event *event,
 	else
 		itrace_synth_opts__set_default(&bts->synth_opts);
 
+	if (bts->synth_opts.calls)
+		bts->branches_filter |= PERF_IP_FLAG_CALL | PERF_IP_FLAG_ASYNC |
+					PERF_IP_FLAG_TRACE_END;
+	if (bts->synth_opts.returns)
+		bts->branches_filter |= PERF_IP_FLAG_RETURN |
+					PERF_IP_FLAG_TRACE_BEGIN;
+
 	err = intel_bts_synth_events(bts, session);
 	if (err)
 		goto err_free_queues;
Signature · 1 line
2.1.0
author maintainer
#35 lore raw

PATCH 35/37 perf tools: Intel PT to always update thread stack trace number

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

The enhanced thread stack is used by higher layers but still requires the trace number. The trace number is used to distinguish discontinuous sections of trace (for example from Snapshot mode or Sample mode), which cause the thread stack to be flushed.

---
 tools/perf/util/intel-pt.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
tools/perf/util/intel-pt.c +3 -1
index 9c25bfadb4f3..5a59fd8e79ae 100644
@@ -265,7 +265,7 @@ static int intel_pt_get_trace(struct intel_pt_buffer *b, void *data)
 	if (!old_buffer || ptq->pt->sampling_mode || (ptq->pt->snapshot_mode &&
 						      !buffer->consecutive)) {
 		b->consecutive = false;
-		b->trace_nr = buffer->buffer_nr;
+		b->trace_nr = buffer->buffer_nr + 1;
 	} else {
 		b->consecutive = true;
 	}
@@ -1075,6 +1075,8 @@ static int intel_pt_sample(struct intel_pt_queue *ptq)
 		thread_stack__event(ptq->thread, ptq->flags, state->from_ip,
 				    state->to_ip, ptq->insn_len,
 				    state->trace_nr);
+	else
+		thread_stack__set_trace_nr(ptq->thread, state->trace_nr);
 
 	if (pt->sample_branches) {
 		err = intel_pt_synth_branch_sample(ptq);
Signature · 1 line
2.1.0
author maintainer
#36 lore raw

PATCH 36/37 perf tools: Intel BTS to always update thread stack trace number

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

The enhanced thread stack is used by higher layers but still requires the trace number. The trace number is used to distinguish discontinuous sections of trace (for example from Snapshot mode or Sample mode), which cause the thread stack to be flushed.

---
 tools/perf/util/intel-bts.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)
tools/perf/util/intel-bts.c +14 -4
index b068860d4940..cd7bde33b635 100644
@@ -27,6 +27,8 @@
 #include "machine.h"
 #include "session.h"
 #include "util.h"
+#include "thread.h"
+#include "thread-stack.h"
 #include "debug.h"
 #include "tsc.h"
 #include "auxtrace.h"
@@ -443,19 +445,22 @@ static int intel_bts_process_buffer(struct intel_bts_queue *btsq,
 
 static int intel_bts_process_queue(struct intel_bts_queue *btsq, u64 *timestamp)
 {
-	struct auxtrace_buffer *buffer = btsq->buffer;
+	struct auxtrace_buffer *buffer = btsq->buffer, *old_buffer = buffer;
 	struct auxtrace_queue *queue;
+	struct thread *thread;
 	int err;
 
 	if (btsq->done)
 		return 1;
 
 	if (btsq->pid == -1) {
-		struct thread *thread;
-
-		thread = machine__find_thread(btsq->bts->machine, -1, btsq->tid);
+		thread = machine__find_thread(btsq->bts->machine, -1,
+					      btsq->tid);
 		if (thread)
 			btsq->pid = thread->pid_;
+	} else {
+		thread = machine__findnew_thread(btsq->bts->machine, btsq->pid,
+						 btsq->tid);
 	}
 
 	queue = &btsq->bts->queues.queue_array[btsq->queue_nr];
@@ -485,6 +490,11 @@ static int intel_bts_process_queue(struct intel_bts_queue *btsq, u64 *timestamp)
 	    intel_bts_do_fix_overlap(queue, buffer))
 		return -ENOMEM;
 
+	if (!btsq->bts->synth_opts.callchain && thread &&
+	    (!old_buffer || btsq->bts->sampling_mode ||
+	     (btsq->bts->snapshot_mode && !buffer->consecutive)))
+		thread_stack__set_trace_nr(thread, buffer->buffer_nr + 1);
+
 	err = intel_bts_process_buffer(btsq, buffer);
 
 	auxtrace_buffer__drop_data(buffer);
Signature · 1 line
2.1.0
author maintainer
#37 lore raw

PATCH 37/37 perf tools: Put itrace options into an asciidoc include

In reply to Arnaldo Carvalho de Melo

From: Adrian Hunter <[email protected]>

perf script, report and inject all have the same itrace options. Put them into an asciidoc include file.

---
 tools/perf/Documentation/itrace.txt      | 22 ++++++++++++++++++++++
 tools/perf/Documentation/perf-inject.txt | 23 +----------------------
 tools/perf/Documentation/perf-report.txt | 23 +----------------------
 tools/perf/Documentation/perf-script.txt | 23 +----------------------
 4 files changed, 25 insertions(+), 66 deletions(-)
 create mode 100644 tools/perf/Documentation/itrace.txt
tools/perf/Documentation/itrace.txt new file +22 -0
new file mode 100644
index 000000000000..2ff946677e3b
@@ -0,0 +1,22 @@
+		i	synthesize instructions events
+		b	synthesize branches events
+		c	synthesize branches events (calls only)
+		r	synthesize branches events (returns only)
+		x	synthesize transactions events
+		e	synthesize error events
+		d	create a debug log
+		g	synthesize a call chain (use with i or x)
+
+	The default is all events i.e. the same as --itrace=ibxe
+
+	In addition, the period (default 100000) for instructions events
+	can be specified in units of:
+
+		i	instructions
+		t	ticks
+		ms	milliseconds
+		us	microseconds
+		ns	nanoseconds (default)
+
+	Also the call chain size (default 16, max. 1024) for instructions or
+	transactions events can be specified.
tools/perf/Documentation/perf-inject.txt +1 -22
index b876ae312699..0c721c3e37e1 100644
@@ -48,28 +48,7 @@ OPTIONS
 	Decode Instruction Tracing data, replacing it with synthesized events.
 	Options are:
 
-		i	synthesize instructions events
-		b	synthesize branches events
-		c	synthesize branches events (calls only)
-		r	synthesize branches events (returns only)
-		x	synthesize transactions events
-		e	synthesize error events
-		d	create a debug log
-		g	synthesize a call chain (use with i or x)
-
-	The default is all events i.e. the same as --itrace=ibxe
-
-	In addition, the period (default 100000) for instructions events
-	can be specified in units of:
-
-		i	instructions
-		t	ticks
-		ms	milliseconds
-		us	microseconds
-		ns	nanoseconds (default)
-
-	Also the call chain size (default 16, max. 1024) for instructions or
-	transactions events can be specified.
+include::itrace.txt[]
 
 SEE ALSO
 --------
tools/perf/Documentation/perf-report.txt +1 -22
index c33b69f3374f..6c449284040e 100644
@@ -328,28 +328,7 @@ OPTIONS
 --itrace::
 	Options for decoding instruction tracing data. The options are:
 
-		i	synthesize instructions events
-		b	synthesize branches events
-		c	synthesize branches events (calls only)
-		r	synthesize branches events (returns only)
-		x	synthesize transactions events
-		e	synthesize error events
-		d	create a debug log
-		g	synthesize a call chain (use with i or x)
-
-	The default is all events i.e. the same as --itrace=ibxe
-
-	In addition, the period (default 100000) for instructions events
-	can be specified in units of:
-
-		i	instructions
-		t	ticks
-		ms	milliseconds
-		us	microseconds
-		ns	nanoseconds (default)
-
-	Also the call chain size (default 16, max. 1024) for instructions or
-	transactions events can be specified.
+include::itrace.txt[]
 
 	To disable decoding entirely, use --no-itrace.
 
tools/perf/Documentation/perf-script.txt +1 -22
index c82df572fac2..ac9e99add007 100644
@@ -231,28 +231,7 @@ OPTIONS
 --itrace::
 	Options for decoding instruction tracing data. The options are:
 
-		i	synthesize instructions events
-		b	synthesize branches events
-		c	synthesize branches events (calls only)
-		r	synthesize branches events (returns only)
-		x	synthesize transactions events
-		e	synthesize error events
-		d	create a debug log
-		g	synthesize a call chain (use with i or x)
-
-	The default is all events i.e. the same as --itrace=ibxe
-
-	In addition, the period (default 100000) for instructions events
-	can be specified in units of:
-
-		i	instructions
-		t	ticks
-		ms	milliseconds
-		us	microseconds
-		ns	nanoseconds (default)
-
-	Also the call chain size (default 16, max. 1024) for instructions or
-	transactions events can be specified.
+include::itrace.txt[]
 
 	To disable decoding entirely, use --no-itrace.
 
Signature · 1 line
2.1.0
#38 lore raw
In reply to Arnaldo Carvalho de Melo
Quoted 21 lines · Arnaldo Carvalho de Melo

Hi Ingo,

	Test built on Fedora21 x86_64, RHEL (5.11 with NO_AUXTRACE=1

NO_LIBPERL=1 NO_LIBNUMA=1, 6.6 and 7.1) all x86_64.

Please consider applying,

- Arnaldo

The following changes since commit d499c106843afa0703a68c64662bf42a16421aec:

Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2015-05-20 13:23:55 +0200)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo

for you to fetch changes up to 264ed8843fe2e4c24422ff61de1e3db609106445:

perf tools: Put itrace options into an asciidoc include (2015-05-26 13:21:08 -0300)

Quoted 8 lines

----------------------------------------------------------------
perf/core improvements and fixes:

New features:

- Intel PT support, should be complete now and possible to test it with what we already have in the kernel, go, test it and report problems on lkml, I'm sure Adrian will chime in if something doesn't work as documented. (Adrian Hunter)

So how can people follow your request?

The changelogs are minimal, sometimes they only say:

From 7a84d68975f34c912cb6ec8adb3c1869c15b5c36 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <[email protected]>
Date: Fri, 22 May 2015 14:54:04 +0300
Subject: [PATCH] perf tools: Add Intel PT support

Add support for Intel Processor Trace.

there's almost zero comments added by these commits.

This commit:

928541b6f51f perf tools: Take Intel PT into use

adds 'some documentation' under ./Documentation/intel-pt.txt, but that text doesn't actually give any high level description, it doesn't give _any_ way for a user to discover Intel PT support on his own - unless he already knows it, which is kind of circular.

It doesn't describe which CPUs support Intel PT, what it is, how are people supposed to use it, what the high level capabilities and limitations are, etc. etc.

So this stuff is user and developer hostile at the moment. We can push this towards Linus only if this becomes _much_ more user and developer friendly. Near zero documentation and near zero comments in the code don't cut it really.

Thanks,

Ingo

author maintainer
#39 lore raw

Em Wed, May 27, 2015 at 09:38:47AM +0200, Ingo Molnar escreveu:

Quoted 8 lines · Arnaldo Carvalho de Melo
Quoted 5 lines

New features:

- Intel PT support, should be complete now and possible to test it with what we already have in the kernel, go, test it and report problems on lkml, I'm sure Adrian will chime in if something doesn't work as documented. (Adrian Hunter)

So how can people follow your request?

First by having access to a machine with these hardware features, which, for one, I have no easy access to right now :-\

Quoted 1 line

The changelogs are minimal, sometimes they only say:

They improved over time, over the many resubmits Adrian made, so some progress was made on this front.

Quoted 8 lines

From 7a84d68975f34c912cb6ec8adb3c1869c15b5c36 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <[email protected]>
Date: Fri, 22 May 2015 14:54:04 +0300
Subject: [PATCH] perf tools: Add Intel PT support

Add support for Intel Processor Trace.

there's almost zero comments added by these commits.

I shouldn't have let some pass, granted.

Quoted 9 lines

This commit:

928541b6f51f perf tools: Take Intel PT into use

adds 'some documentation' under ./Documentation/intel-pt.txt, but that text doesn't actually give any high level description, it doesn't give _any_ way for a user to discover Intel PT support on his own - unless he already knows it, which is kind of circular.

Quoted 7 lines

It doesn't describe which CPUs support Intel PT, what it is, how are people supposed to use it, what the high level capabilities and limitations are, etc. etc.

So this stuff is user and developer hostile at the moment. We can push this towards Linus only if this becomes _much_ more user and developer friendly. Near zero documentation and near zero comments in the code don't cut it really.

Adrian, can you try to address this further, please?

Something like a handholding session, so that we don't have to dig thru all the csets or patch series cover letters, telling:

1. What hardware one has to have to be able to test it

2. First command to use

3. What will be generated, how much space (a lot?) it will use on the perf.data file, etc.

5. What commands have to be used on this perf.data file and what to expect from it.

I.e. a HOWTO that starts with a as short as possible description on how
to use it for the very first time, for people never exposed to Intel PT
but that can benefit from using it.

Ingo, so I'll move these csets to a separate branch from where I can work with Adrian and others to then try again to resubmit, but only on a branch exclusively for this.

Will resubmit a perf/core branch with the remaining bits soon.

- Arnaldo

reviewer
#40 lore raw
Quoted 42 lines · Arnaldo Carvalho de Melo

Em Wed, May 27, 2015 at 09:38:47AM +0200, Ingo Molnar escreveu:

Quoted 8 lines · Arnaldo Carvalho de Melo
Quoted 5 lines

New features:

- Intel PT support, should be complete now and possible to test it with what we already have in the kernel, go, test it and report problems on lkml, I'm sure Adrian will chime in if something doesn't work as documented. (Adrian Hunter)

So how can people follow your request?

First by having access to a machine with these hardware features, which, for one, I have no easy access to right now :-\

Quoted 1 line

The changelogs are minimal, sometimes they only say:

They improved over time, over the many resubmits Adrian made, so some progress was made on this front.

Quoted 8 lines

From 7a84d68975f34c912cb6ec8adb3c1869c15b5c36 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <[email protected]>
Date: Fri, 22 May 2015 14:54:04 +0300
Subject: [PATCH] perf tools: Add Intel PT support

Add support for Intel Processor Trace.

there's almost zero comments added by these commits.

I shouldn't have let some pass, granted.

Quoted 12 lines

This commit:

928541b6f51f perf tools: Take Intel PT into use

adds 'some documentation' under ./Documentation/intel-pt.txt, but that text doesn't actually give any high level description, it doesn't give _any_ way for a user to discover Intel PT support on his own - unless he already knows it, which is kind of circular.

It doesn't describe which CPUs support Intel PT, what it is, how are people supposed to use it, what the high level capabilities and limitations are, etc. etc.

Quoted 5 lines
Quoted 3 lines

So this stuff is user and developer hostile at the moment. We can push this towards Linus only if this becomes _much_ more user and developer friendly. Near zero documentation and near zero comments in the code don't cut it really.

Adrian, can you try to address this further, please?

Yes, I will mainly expand the information in tools/perf/Documentation/intel-pt.txt unless you have any other ideas.

Quoted 27 lines

Something like a handholding session, so that we don't have to dig thru all the csets or patch series cover letters, telling:

1. What hardware one has to have to be able to test it

2. First command to use

3. What will be generated, how much space (a lot?) it will use on the perf.data file, etc.

5. What commands have to be used on this perf.data file and what to expect from it.

I.e. a HOWTO that starts with a as short as possible description on how
to use it for the very first time, for people never exposed to Intel PT
but that can benefit from using it.

Ingo, so I'll move these csets to a separate branch from where I can work with Adrian and others to then try again to resubmit, but only on a branch exclusively for this.

Will resubmit a perf/core branch with the remaining bits soon.

- Arnaldo

#41 lore raw
In reply to Arnaldo Carvalho de Melo
Quoted 12 lines · Arnaldo Carvalho de Melo

Adrian, can you try to address this further, please?

Something like a handholding session, so that we don't have to dig thru all the csets or patch series cover letters, telling:

1. What hardware one has to have to be able to test it

2. First command to use

3. What will be generated, how much space (a lot?) it will use on the perf.data file, etc.

Quoted 6 lines

5. What commands have to be used on this perf.data file and what to expect from it.

I.e. a HOWTO that starts with a as short as possible description on how
to use it for the very first time, for people never exposed to Intel PT
but that can benefit from using it.

Yeah, a HOWTO or a QuickStart file would be a good first step I suspect.

Quoted 5 lines

Ingo, so I'll move these csets to a separate branch from where I can work with Adrian and others to then try again to resubmit, but only on a branch exclusively for this.

Will resubmit a perf/core branch with the remaining bits soon.

Sounds good to me!

Thanks,

Ingo

reviewer
#42 lore raw
In reply to Arnaldo Carvalho de Melo
Quoted 58 lines · Arnaldo Carvalho de Melo

Em Wed, May 27, 2015 at 09:38:47AM +0200, Ingo Molnar escreveu:

Quoted 8 lines · Arnaldo Carvalho de Melo
Quoted 5 lines

New features:

- Intel PT support, should be complete now and possible to test it with what we already have in the kernel, go, test it and report problems on lkml, I'm sure Adrian will chime in if something doesn't work as documented. (Adrian Hunter)

So how can people follow your request?

First by having access to a machine with these hardware features, which, for one, I have no easy access to right now :-\

Quoted 1 line

The changelogs are minimal, sometimes they only say:

They improved over time, over the many resubmits Adrian made, so some progress was made on this front.

Quoted 8 lines

From 7a84d68975f34c912cb6ec8adb3c1869c15b5c36 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <[email protected]>
Date: Fri, 22 May 2015 14:54:04 +0300
Subject: [PATCH] perf tools: Add Intel PT support

Add support for Intel Processor Trace.

there's almost zero comments added by these commits.

I shouldn't have let some pass, granted.

Quoted 9 lines

This commit:

928541b6f51f perf tools: Take Intel PT into use

adds 'some documentation' under ./Documentation/intel-pt.txt, but that text doesn't actually give any high level description, it doesn't give _any_ way for a user to discover Intel PT support on his own - unless he already knows it, which is kind of circular.

Quoted 7 lines

It doesn't describe which CPUs support Intel PT, what it is, how are people supposed to use it, what the high level capabilities and limitations are, etc. etc.

So this stuff is user and developer hostile at the moment. We can push this towards Linus only if this becomes _much_ more user and developer friendly. Near zero documentation and near zero comments in the code don't cut it really.

Adrian, can you try to address this further, please?

Something like a handholding session, so that we don't have to dig thru all the csets or patch series cover letters, telling:

1. What hardware one has to have to be able to test it

2. First command to use

3. What will be generated, how much space (a lot?) it will use on the perf.data file, etc.

Quoted 6 lines

5. What commands have to be used on this perf.data file and what to expect from it.

I.e. a HOWTO that starts with a as short as possible description on how
to use it for the very first time, for people never exposed to Intel PT
but that can benefit from using it.

I sent the patches again a week ago, but perhaps no one noticed. They are here:

	http://marc.info/?l=linux-kernel&m=143290658028132

Comments welcome :-)

author maintainer
#43 lore raw

Em Fri, Jun 05, 2015 at 04:21:44PM +0300, Adrian Hunter escreveu:

Quoted 25 lines · Arnaldo Carvalho de Melo
Quoted 17 lines

Em Wed, May 27, 2015 at 09:38:47AM +0200, Ingo Molnar escreveu:

Quoted 3 lines

So this stuff is user and developer hostile at the moment. We can push this towards Linus only if this becomes _much_ more user and developer friendly. Near zero documentation and near zero comments in the code don't cut it really.

Adrian, can you try to address this further, please?

Something like a handholding session, so that we don't have to dig thru all the csets or patch series cover letters, telling:

1. What hardware one has to have to be able to test it

2. First command to use

3. What will be generated, how much space (a lot?) it will use on the perf.data file, etc.

Quoted 6 lines

5. What commands have to be used on this perf.data file and what to expect from it.

I.e. a HOWTO that starts with a as short as possible description on how
to use it for the very first time, for people never exposed to Intel PT
but that can benefit from using it.

Quoted 5 lines

I sent the patches again a week ago, but perhaps no one noticed. They are here:

	http://marc.info/?l=linux-kernel&m=143290658028132

Comments welcome :-)

I saw it, was just busy with other stuff and was waiting for other people to chime in, will look for that 'handholding session' and also for a broadwell machine were I can try to follow it.

- Arnaldo