kernel/tools/perf/util, branch linux-3.11.y

perf tools: Fix perf version generation

2013-07-08T21:09:52Z

The tag of the perf version is wrongly determined, always the latest tag is taken regardless of the HEAD commit: $ perf --version perf version 3.9.rc8.gd7f5d3 $ git describe d7f5d3 v3.9-rc7-154-gd7f5d33 $ head -n 4 Makefile VERSION = 3 PATCHLEVEL = 9 SUBLEVEL = 0 EXTRAVERSION = -rc7 In other cases no tag might be found. This patch fixes this. This new implementation handles also the case if there are no tags at all found in the git repo but there is a commit id. Signed-off-by: Robert Richter Link: http://lkml.kernel.org/r/1368006214-12912-1-git-send-email-rric@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Fix vdso list searching

2013-07-08T20:59:07Z

When "perf record" was used on a large machine with a lot of CPUs, the perf post-processing time (the time after the workload was done until the perf command itself exited) could take a lot of minutes and even hours depending on how large the resulting perf.data file was. While running AIM7 1500-user high_systime workload on a 80-core x86-64 system with a 3.9 kernel (with only the -s -a options used), the workload itself took about 2 minutes to run and the perf.data file had a size of 1108.746 MB. However, the post-processing step took more than 10 minutes. With a gprof-profiled perf binary, the time spent by perf was as follows: % cumulative self self total time seconds seconds calls s/call s/call name 96.90 822.10 822.10 192156 0.00 0.00 dsos__find 0.81 828.96 6.86 172089958 0.00 0.00 rb_next 0.41 832.44 3.48 48539289 0.00 0.00 rb_erase So 97% (822 seconds) of the time was spent in a single dsos_find() function. After analyzing the call-graph data below: ----------------------------------------------- 0.00 822.12 192156/192156 map__new [6] [7] 96.9 0.00 822.12 192156 vdso__dso_findnew [7] 822.10 0.00 192156/192156 dsos__find [8] 0.01 0.00 192156/192156 dsos__add [62] 0.01 0.00 192156/192366 dso__new [61] 0.00 0.00 1/45282525 memdup [31] 0.00 0.00 192156/192230 dso__set_long_name [91] ----------------------------------------------- 822.10 0.00 192156/192156 vdso__dso_findnew [7] [8] 96.9 822.10 0.00 192156 dsos__find [8] ----------------------------------------------- It was found that the vdso__dso_findnew() function failed to locate VDSO__MAP_NAME ("[vdso]") in the dso list and have to insert a new entry at the end for 192156 times. This problem is due to the fact that there are 2 types of name in the dso entry - short name and long name. The initial dso__new() adds "[vdso]" to both the short and long names. After that, vdso__dso_findnew() modifies the long name to something like /tmp/perf-vdso.so-NoXkDj. The dsos__find() function only compares the long name. As a result, the same vdso entry is duplicated many time in the dso list. This bug increases memory consumption as well as slows the symbol processing time to a crawl. To resolve this problem, the dsos__find() function interface was modified to enable searching either the long name or the short name. The vdso__dso_findnew() will now search only the short name while the other call sites search for the long name as before. With this change, the cpu time of perf was reduced from 848.38s to 15.77s and dsos__find() only accounted for 0.06% of the total time. 0.06 15.73 0.01 192151 0.00 0.00 dsos__find Signed-off-by: Waiman Long Acked-by: Ingo Molnar Cc: "Chandramouleeswaran, Aswin" Cc: "Norton, Scott J" Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1368110568-64714-1-git-send-email-Waiman.Long@hp.com [ replaced TRUE/FALSE with stdbool.h equivalents, fixing builds where those macros are not present (NO_LIBPYTHON=1 NO_LIBPERL=1), fix from Jiri Olsa ] Signed-off-by: Arnaldo Carvalho de Melo

perf evsel: Fix missing increment in sample parsing

2013-07-08T20:47:13Z

The final sample format bit used to be PERF_SAMPLE_STACK_USER which neglected to do a final increment of the array pointer. The result is that the following parsing might start at the wrong place. Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1372944040-32690-16-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Update symbol_conf.nr_events when processing attribute events

2013-07-08T20:46:39Z

Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1372944040-32690-11-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix new_term() missing free on error path

2013-07-08T20:45:56Z

On the error path, newly allocated 'term' must be freed. Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1372944040-32690-6-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix parse_events_terms() segfault on error path

2013-07-08T20:45:41Z

On the error path, 'data.terms' may not have been initialised. Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1372944040-32690-5-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf evsel: Fix count parameter to read call in event_format__new

2013-07-08T20:40:39Z

per realloc above the length of the buffer is alloc_size, not BUFSIZ. Adjust length per size as done for buf start. Addresses some valgrind complaints: ==1870== Syscall param read(buf) points to unaddressable byte(s) ==1870== at 0x4E3F610: __read_nocancel (in /lib64/libpthread-2.14.90.so) ==1870== by 0x44AEE1: event_format__new (unistd.h:45) ==1870== by 0x44B025: perf_evsel__newtp (evsel.c:158) ==1870== by 0x451919: add_tracepoint_event (parse-events.c:395) ==1870== by 0x479815: parse_events_parse (parse-events.y:292) ==1870== by 0x45463A: parse_events_option (parse-events.c:861) ==1870== by 0x44FEE4: get_value (parse-options.c:113) ==1870== by 0x450767: parse_options_step (parse-options.c:192) ==1870== by 0x450C40: parse_options (parse-options.c:422) ==1870== by 0x42735F: cmd_record (builtin-record.c:918) ==1870== by 0x419D72: run_builtin (perf.c:319) ==1870== by 0x4195F2: main (perf.c:376) ==1870== Address 0xcffebf0 is 0 bytes after a block of size 8,192 alloc'd ==1870== at 0x4C2A62F: malloc (vg_replace_malloc.c:270) ==1870== by 0x4C2A7A3: realloc (vg_replace_malloc.c:662) ==1870== by 0x44AF07: event_format__new (evsel.c:121) ==1870== by 0x44B025: perf_evsel__newtp (evsel.c:158) ==1870== by 0x451919: add_tracepoint_event (parse-events.c:395) ==1870== by 0x479815: parse_events_parse (parse-events.y:292) ==1870== by 0x45463A: parse_events_option (parse-events.c:861) ==1870== by 0x44FEE4: get_value (parse-options.c:113) ==1870== by 0x450767: parse_options_step (parse-options.c:192) ==1870== by 0x450C40: parse_options (parse-options.c:422) ==1870== by 0x42735F: cmd_record (builtin-record.c:918) ==1870== by 0x419D72: run_builtin (perf.c:319) Signed-off-by: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1372793245-4136-2-git-send-email-dsahern@gmail.com Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix -x/--exclude-other option for report command

2013-07-08T20:38:53Z

Currently we have symbol_conf.exclude_other being set as true every time so the -x/--exclude-other has nothing to do. Also we have no way to see the data with symbol_conf.exclude_other being false which is useful sometimes. Fixing it by making symbol_conf.exclude_other false by default. 1) Example without -x option: $ perf report -i perf.data.delete -p perf_session__delete -s parent + 99.91% [other] + 0.08% perf_session__delete + 0.00% perf_session__delete_dead_threads + 0.00% perf_session__delete_threads 2) Example with -x option: $ ./perf report -i perf.data.delete -p perf_session__delete -s parent -x + 96.22% perf_session__delete + 1.89% perf_session__delete_dead_threads + 1.89% perf_session__delete_threads In Example 1) we get the sorted out data together with the rest "[other]". This could help us estimate how much time we spent in the sorted data. In Example 2) the total is just the sorted data. Signed-off-by: Jiri Olsa Cc: Andi Kleen Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-sg8fvu0fyqohf9ur9l38lhkw@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf evlist: Enhance perf_evlist__start_workload()

2013-07-08T20:38:30Z

When perf tries to start a workload, it relies on a pipe which the workload was blocked for reading. After closing the pipe on the parent, the workload (child) can start the actual work via exec(). However, if another process was forked after creating a workload, this mechanism cannot work since the other process (child) also inherits the pipe, so that closing the pipe in parent cannot unblock the workload. Fix it by using explicit write call can then closing it. For similar reason, the pipe fd on parent should be marked as CLOEXEC so that it can be closed after another child exec'ed. Signed-off-by: Namhyung Kim Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Steven Rostedt Link: http://lkml.kernel.org/r/1372230862-15861-13-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf record: Remove -A/--append option

2013-07-08T20:37:10Z

It's no longer working and needed. Quite straightforward discussion/vote was in here: http://marc.info/?t=137028288300004&r=1&w=2 Signed-off-by: Jiri Olsa Cc: Andi Kleen Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-8fgdva12hl8w3xzzpsvvg7nx@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo