linux/tools/perf/util/map.c, branch v3.4.33

perf annotate: Validate addr in symbol__inc_addr_samples

2012-04-05T22:51:14Z

This routine was checking only if the provided address was after sym->end, not if it was before sym->start. Fix that by checking for both and return in both cases -ERANGE, so that tools can communicate this to the user properly, or if they chose so, to abort. This problem was reported previously but the fixes involved either doing what was being done for the > end case, i.e. silently drop the sample, returning 0, or aborting at this function, which is in a lib (or better, is slated to be at some point) and shouldn't abort. The 'report' tool already checks this value and uses pr_debug to warn the user. This patch makes the 'top' tool check it too and warn once per map where such range problem takes place. Reported-by: David Miller Reported-by: Sorin Dumitru Reported-by: Stephane Eranian Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-lw8gs7p9i9nhldilo82tzpne@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf script: Add option resolving vmlinux path

2012-01-30T20:13:07Z

Add the option get the path of [kernel.kallsyms]. Specify '--show-kernel-path' option to use this function. This patch enables other applications to use this output easily. Without --show-kernel-path option ffffffff81467612 irq_return ([kernel.kallsyms]) ffffffff81467612 irq_return ([kernel.kallsyms]) 7f24fc02a6b3 _start (/lib64/ld-2.14.so) [snip] With --show-kernel-path option ffffffff81467612 irq_return (/lib/modules/3.2.0+/build/vmlinux) ffffffff81467612 irq_return (/lib/modules/3.2.0+/build/vmlinux) 7f24fc02a6b3 _start (/lib64/ld-2.14.so) [snip] Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Masami Hiramatsu Cc: Paul Mackerras Cc: Peter Zijlstra Cc: yrl.pp-manager.tt@hitachi.com Link: http://lkml.kernel.org/r/20120130044320.2384.73322.stgit@linux3 Signed-off-by: Akihiro Nagai Signed-off-by: Arnaldo Carvalho de Melo

perf script: Unify the expressions indicating "unknown"

2012-01-30T19:57:57Z

The perf script command uses various expressions to indicate "unknown". It is unfriendly for user scripts to parse it. So, this patch unifies the expressions to "[unknown]". Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Masami Hiramatsu Cc: Paul Mackerras Cc: Peter Zijlstra Cc: yrl.pp-manager.tt@hitachi.com Link: http://lkml.kernel.org/r/20120130044257.2384.62905.stgit@linux3 Signed-off-by: Akihiro Nagai Signed-off-by: Arnaldo Carvalho de Melo

perf session: Move threads to struct machine

2011-11-28T12:35:31Z

The 'machine' abstraction was introduced with 'perf kvm' where we could have samples for the host and multiple guests, but at the time we ended up keeping the list of all machines threads all in session->host_machine. Move the threads rb_tree to struct machine to separate the namespaces. 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-mdg7sm6j3va09vtgj49gbsrp@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Add prelink suggestion to dso update message

2011-10-19T15:13:43Z

Following a prelink run mapped files for long running processes can show as deleted. The current message suggests restarting long running processes. Add to that a suggestion that prelink might be the cause. Old message: /lib64/libc-2.14.so was updated, restart the long running apps that use it! New message: /lib64/libc-2.14.so was updated (is prelink enabled?). Restart the long running apps that use it! Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1318985085-20776-1-git-send-email-dsahern@gmail.com Signed-off-by: David Ahern Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Treat all memory maps without dso file as loaded

2011-09-29T20:10:48Z

The stack/vdso/heap memory maps dont have any dso file. Setting the perf dso objects as 'loaded' for these maps, we avoid unnecessary warnings like: "Failed to open [stack], continuing without symbols" All map__find_* functions still return NULL when searching for symbols in these maps. Link: http://lkml.kernel.org/r/20110824131834.GA2007@jolsa.brq.redhat.com Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Jiri Olsa Signed-off-by: Arnaldo Carvalho de Melo

perf symbols: Stop using 'self' in map_groups__ methods

2011-09-29T19:41:36Z

Stop using this python/OOP convention, doesn't really helps. Will do more from time to time till we get it cleaned up in all of /perf. Suggested-by: Thomas Gleixner 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-rl9e690y60vnuyng05yp1zd3@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix 64 bit integer format strings

2011-01-23T01:41:57Z

Using %L[uxd] has issues in some architectures, like on ppc64. Fix it by making our 64 bit integers typedefs of stdint.h types and using PRI[ux]64 like, for instance, git does. Reported by Denis Kirjanov that provided a patch for one case, I went and changed all cases. Reported-by: Denis Kirjanov Tested-by: Denis Kirjanov LKML-Reference: <20110120093246.GA8031@hera.kernel.org> Cc: Denis Kirjanov Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Pingtian Han Cc: Stephane Eranian Cc: Tom Zanussi Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Don't keep unreferenced maps when unmaps are detected

2010-08-02T22:45:23Z

For a file with: [root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events: TOTAL events: 36933 MMAP events: 9056 LOST events: 0 COMM events: 1702 EXIT events: 1887 THROTTLE events: 8 UNTHROTTLE events: 8 FORK events: 1894 READ events: 0 SAMPLE events: 22378 ATTR events: 0 EVENT_TYPE events: 0 TRACING_DATA events: 0 BUILD_ID events: 0 [root@emilia linux-2.6-tip]# Testing with valgrind and making perf_session__delete() a nop, so that we can notice how many maps were actually deleted due to not having any samples on it: ==== HEAP SUMMARY: Before: ==10339== in use at exit: 8,909,997 bytes in 68,690 blocks ==10339== total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated After: ==10506== in use at exit: 8,902,605 bytes in 68,606 blocks ==10506== total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated I.e. just 84 detected unmaps with no hits out of 9056 for this workload, not much, but in some other long running workload this may save more bytes. Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Stephane Eranian LKML-Reference: Signed-off-by: Arnaldo Carvalho de Melo

perf session: Free the ref_reloc_sym memory at the right place

2010-08-02T21:18:28Z

Which is at perf_session__destroy_kernel_maps, counterpart to the perf_session__create_kernel_maps where the kmap structure is located, just after the vmlinux_maps. Make it also check if the kernel maps were actually created, which may not be the case if, for instance, perf_session__new can't complete due to permission problems in, for instance, a 'perf report' case, when a segfault will take place, that is how this was noticed. The problem was introduced in d65a458, thus post .35. This also adds code to release guest machines as them are also created in perf_session__create_kernel_maps, so should be deleted on this newly introduced counterpart, perf_session__destroy_kernel_maps. Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Stephane Eranian LKML-Reference: Signed-off-by: Arnaldo Carvalho de Melo