linux/tools, branch v3.1

perf tools: Fix raw sample reading

2011-09-29T19:29:53Z

Wrong pointer is being passed for raw data sanity checking, when parsing sample event. This ends up with invalid event and perf record being stuck in __perf_session__process_events function during processing build IDs (process_buildids function). Following command hangs up in my setup: ./perf record -e raw_syscalls:sys_enter ls The fix is to use proper pointer to the raw data instead of the 'u' union. Reviewed-by: David Ahern Cc: David Ahern Cc: Eric Dumazet Cc: Ingo Molnar Cc: Neil Horman Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/1317308709-9474-2-git-send-email-jolsa@redhat.com Signed-off-by: Jiri Olsa Signed-off-by: Arnaldo Carvalho de Melo

perf python: Add missing perf_event__parse_sample 'swapped' parm

2011-09-23T18:38:53Z

Problem introduced in 936be50, that missed one perf_event__parse_sample user, the python binding. Reported-by: Linus Torvalds Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-ja4phms9618ggi657plyuch2@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Add support for disabling -Werror via WERROR=0

2011-09-23T17:38:07Z

GCC often introduces new warnings with lots of false positives - breaking -Werror builds. WERROR=0 allows one to build perf without much fuss - while still encouraging people to send patches to avoid the fuss of having to type WERROR=0. Bisecting back to commits that produce a (mostly harmless) warning on some compilers is more difficult. With WERROR=0 one could bisect without worrying about harmless warnings. Cc: Ingo Molnar Link: http://lkml.kernel.org/r/eac06c7cc4920e5d4830417d466161fb26c7359c.1315514559.git.dvhart@linux.intel.com Signed-off-by: Darren Hart Signed-off-by: Arnaldo Carvalho de Melo

perf top: Fix userspace sample addr map offset

2011-09-23T17:37:54Z

The 'perf top' tool came from the kernel where we had each DSO (vmlinux, modules) loaded just once at a time. But userspace may have DSOs loaded in multiple addresses (shared libraries), requiring that we use the just resolved map instead of the first one found. Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-ag53wz0yllpgers0n2w7hchp@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Fix issue with binaries using 16-bytes buildids (v2)

2011-09-23T17:37:41Z

Buildid can vary in size. According to the man page of ld, buildid can be 160 bits (sha1) or 128 bits (md5, uuid). Perf assumes buildid size of 20 bytes (160 bits) regardless. When dealing with md5 buildids, it would thus read more than needed and that would cause mismatches and samples without symbols. This patch fixes this by taking into account the actual buildid size as encoded int he section header. The leftover bytes are also cleared. This second version fixes a minor issue with the memset() base position. Cc: David S. Miller Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Robert Richter Cc: Stephane Eranian Link: http://lkml.kernel.org/r/4cc1af3c.8ee7d80a.5a28.ffff868e@mx.google.com Signed-off-by: Stephane Eranian Signed-off-by: Arnaldo Carvalho de Melo

perf tool: Fix endianness handling of u32 data in samples

2011-09-23T17:37:27Z

Currently, analyzing PPC data files on x86 the cpu field is always 0 and the tid and pid are backwards. For example, analyzing a PPC file on PPC the pid/tid fields show: rsyslogd 1210/1212 and analyzing the same PPC file using an x86 perf binary shows: rsyslogd 1212/1210 The problem is that the swap_op method for samples is perf_event__all64_swap which assumes all elements in the sample_data struct are u64s. cpu, tid and pid are u32s and need to be handled individually. Given that the swap is done before the sample is parsed, the simplest solution is to undo the 64-bit swap of those elements when the sample is parsed and do the proper swap. The RAW data field is generic and perf cannot have programmatic knowledge of how to treat that data. Instead a warning is given to the user. Thanks to Anton Blanchard for providing a data file for a mult-CPU PPC system so I could verify the fix for the CPU fields. v3 -> v4: - fixed use of WARN_ONCE v2 -> v3: - used WARN_ONCE for message regarding raw data - removed struct wrapper around union - fixed whitespace issues v1 -> v2: - added a union for undoing the byte-swap on u64 and redoing swap on u32's to address compiler errors (see git commit 65014ab3) Cc: Anton Blanchard Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1315321946-16993-1-git-send-email-dsahern@gmail.com Signed-off-by: David Ahern Signed-off-by: Arnaldo Carvalho de Melo

perf sort: Fix symbol sort output by separating unresolved samples by type

2011-09-23T17:37:17Z

I took a profile that suggested 60% of total CPU time was in the hypervisor: ... 60.20% [H] 0x33d43c 4.43% [k] ._spin_lock_irqsave 1.07% [k] ._spin_lock Using perf stat to get the user/kernel/hypervisor breakdown contradicted this. The problem is we merge all unresolved samples into the one unknown bucket. If add a comparison by sample type to sort__sym_cmp we get the real picture: ... 57.11% [.] 0x80fbf63c 4.43% [k] ._spin_lock_irqsave 1.07% [k] ._spin_lock 0.65% [H] 0x33d43c So it was almost all userspace, not hypervisor as the initial profile suggested. I found another issue while adding this. Symbol sorting sometimes shows multiple entries for the unknown bucket: ... 16.65% [.] 0x6cd3a8 7.25% [.] 0x422460 5.37% [.] yylex 4.79% [.] malloc 4.78% [.] _int_malloc 4.03% [.] _int_free 3.95% [.] hash_source_code_string 2.82% [.] 0x532908 2.64% [.] 0x36b538 0.94% [H] 0x8000000000e132a4 0.82% [H] 0x800000000000e8b0 This happens because we aren't consistent with our sorting. On one hand we check to see if both symbols match and for two unresolved samples sym is NULL so we match: if (left->ms.sym == right->ms.sym) return 0; On the other hand we use sample IP for unresolved samples when comparing against a symbol: ip_l = left->ms.sym ? left->ms.sym->start : left->ip; ip_r = right->ms.sym ? right->ms.sym->start : right->ip; This means unresolved samples end up spread across the rbtree and we can't merge them all. If we use cmp_null all unresolved samples will end up in the one bucket and the output makes more sense: ... 39.12% [.] 0x36b538 5.37% [.] yylex 4.79% [.] malloc 4.78% [.] _int_malloc 4.03% [.] _int_free 3.95% [.] hash_source_code_string 2.26% [H] 0x800000000000e8b0 Acked-by: Eric B Munson Cc: Eric B Munson Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Ian Munsie Link: http://lkml.kernel.org/r/20110831115145.4f598ab2@kryten Signed-off-by: Anton Blanchard Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Synthesize anonymous mmap events

2011-09-23T17:37:06Z

perf_event__synthesize_mmap_events does not create anonymous mmap events even though the kernel does. As a result an already running application with dynamically created code will not get profiled - all samples end up in the unknown bucket. This patch skips any entries with '[' in the name to avoid adding events for special regions (eg the vsyscall page). All other executable mmaps are assumed to be anonymous and an event is synthesized. Acked-by: Pekka Enberg Cc: Eric B Munson Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Pekka Enberg Link: http://lkml.kernel.org/r/20110830091506.60b51fe8@kryten Signed-off-by: Anton Blanchard Signed-off-by: Arnaldo Carvalho de Melo

perf record: Create events initially disabled and enable after init

2011-09-23T17:36:53Z

perf-record currently creates events enabled. When doing a system wide collection (-a arg) this causes data collection for perf's initialization activities -- eg., perf_event__synthesize_threads(). For some events (e.g., context switch S/W event or tracepoints like syscalls) perf's initialization causes a lot of events to be captured frequently generating "Check IO/CPU overload!" warnings on larger systems (e.g., 2 socket, quad core, hyperthreading). perf's initialization phase can be skipped by creating events disabled and then enabling them once the initialization is done. Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1314289075-14706-1-git-send-email-dsahern@gmail.com Signed-off-by: David Ahern Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Add some heuristics for choosing the best duplicate symbol

2011-09-23T17:36:36Z

Try and pick the best symbol based on a few heuristics: - Prefer a non weak symbol over a weak one - Prefer a global symbol over a non global one - Prefer a symbol with less underscores (idea taken from kallsyms.c) - If all else fails, choose the symbol with the longest name Cc: Eric B Munson Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20110824065243.161953371@samba.org Signed-off-by: Anton Blanchard Signed-off-by: Arnaldo Carvalho de Melo