linux-toradex.git/tools, branch v2.6.34.2

perf: Resurrect flat callchains

2010-08-02T17:29:43+00:00

commit 97aa1052739c6a06cb6b0467dbf410613d20bc97 upstream.

Initialize the callchain radix tree root correctly.

When we walk through the parents, we must stop after the root, but
since it wasn't well initialized, its parent pointer was random.

Also the number of hits was random because uninitialized, hence it
was part of the callchain while the root doesn't contain anything.

This fixes segfaults and percentages followed by empty callchains
while running:

	perf report -g flat

Reported-by: Ingo Molnar 
Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

perf top: Properly notify the user that vmlinux is missing

2010-07-05T18:21:55+00:00

commit b0a9ab62ab96e258a0ddd81d7fe2719c3db36006 upstream.

Before this patch this message would very briefly appear on the
screen and then the screen would get updates only on the top,
for number of interrupts received, etc, but no annotation would
be performed:

 [root@doppio linux-2.6-tip]# perf top -s n_tty_write > /tmp/bla
 objdump: '[kernel.kallsyms]': No such file

Now this is what the user gets:

 [root@doppio linux-2.6-tip]# perf top -s n_tty_write
 Can't annotate n_tty_write: No vmlinux file was found in the
 path: [0] vmlinux
 [1] /boot/vmlinux
 [2] /boot/vmlinux-2.6.33-rc5
 [3] /lib/modules/2.6.33-rc5/build/vmlinux
 [4] /usr/lib/debug/lib/modules/2.6.33-rc5/vmlinux
 [root@doppio linux-2.6-tip]#

This bug was introduced when we added automatic search for
vmlinux, before that time the user had to specify a vmlinux
file.

Reported-by: David S. Miller 
Reported-by: Ingo Molnar 
Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <1268664418-28328-2-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Fix endianness argument compatibility with OPT_BOOLEAN() and introduce OPT_INCR()

2010-07-05T18:21:54+00:00

commit c05556421742eb47f80301767653a4bcb19de9de upstream.

Parsing an option from the command line with OPT_BOOLEAN on a
bool data type would not work on a big-endian machine due to the
manner in which the boolean was being cast into an int and
incremented. For example, running 'perf probe --list' on a
PowerPC machine would fail to properly set the list_events bool
and would therefore print out the usage information and
terminate.

This patch makes OPT_BOOLEAN work as expected with a bool
datatype. For cases where the original OPT_BOOLEAN was
intentionally being used to increment an int each time it was
passed in on the command line, this patch introduces OPT_INCR
with the old behaviour of OPT_BOOLEAN (the verbose variable is
currently the only such example of this).

I have reviewed every use of OPT_BOOLEAN to verify that a true
C99 bool was passed. Where integers were used, I verified that
they were only being used for boolean logic and changed them to
bools to ensure that they would not be mistakenly used as ints.
The major exception was the verbose variable which now uses
OPT_INCR instead of OPT_BOOLEAN.

Signed-off-by: Ian Munsie 
Acked-by: David S. Miller 
Cc: 
Cc: Git development list 
Cc: Ian Munsie 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: KOSAKI Motohiro 
Cc: Hitoshi Mitake 
Cc: Rusty Russell 
Cc: Frederic Weisbecker 
Cc: Eric B Munson 
Cc: Valdis.Kletnieks@vt.edu
Cc: WANG Cong 
Cc: Thiago Farina 
Cc: Masami Hiramatsu 
Cc: Xiao Guangrong 
Cc: Jaswinder Singh Rajput 
Cc: Arjan van de Ven 
Cc: OGAWA Hirofumi 
Cc: Mike Galbraith 
Cc: Tom Zanussi 
Cc: Anton Blanchard 
Cc: John Kacur 
Cc: Li Zefan 
Cc: Steven Rostedt 
LKML-Reference: <1271147857-11604-1-git-send-email-imunsie@au.ibm.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf record: Add a fallback to the reference relocation symbol

2010-05-13T05:55:29+00:00

Usually "_text" is enough, but I received reports that its not always
available, so fallback to "_stext" for the symbol we use to check if we
need to apply any relocation to all the symbols in the kernel symtab,
for when, for instance, kexec is being used.

Reported-by: Darren Hart 
Reported-by: Steven Rostedt 
Cc: Frédéric Weisbecker 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Ingo Molnar

perf: Fix static strings treated like dynamic ones

2010-05-11T07:14:24+00:00

The raw_field_ptr() helper, used to retrieve the address of a field
inside a trace event, treats every strings as if they were dynamic
ie: having a secondary level of indirection to retrieve their
contents.

FIELD_IS_STRING doesn't mean FIELD_IS_DYNAMIC, we only need to
compute the secondary dereference for the latter case.

This fixes perf sched segfaults, bad cmdline report and may be
some other bugs.

Reported-by: Jason Baron 
Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Tom Zanussi

perf kmem: Fix breakage introduced by 5a0e3ad slab.h script

2010-04-06T15:48:06+00:00

Commit 5a0e3ad ("include cleanup: Update gfp.h and slab.h
includes to prepare for breaking implicit slab.h inclusion
from percpu.h") added a '#include ' to
tools/perf/builtin-kmem.h because: that tool has lines like
this:

        if (!strcmp(event->name, "kmalloc") ||
            !strcmp(event->name, "kmem_cache_alloc")) {
                process_alloc_event(data, event, cpu, timestamp, thread, 0);
                return;
        }

So, using the script regex:

>>> import re
>>> s = re.compile(r'^(|.*[^a-zA-Z0-9_])_*(slab_is_available|kmem_cache_|k[mzc]alloc|krealloc|kz?free|ksize|__getname|putname)')
>>> l = '   !strcmp(event->name, "kmem_cache_alloc")) {'
>>> s.search(l)
<_sre.SRE_Match object at 0xb77b1ad0>
>>>

Remove that file that is not available in the tools/perf include
path and thus builtin-kmem.c couldn't be compiled.

Reported-by: Peter Zijlstra 
Cc: Christoph Lameter 
Cc: Frédéric Weisbecker 
Cc: Lee Schermerhorn 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Tejun Heo 
Cc: Linus Torvalds 
LKML-Reference: <1270561053-14308-1-git-send-email-acme@infradead.org>
Signed-off-by: Ingo Molnar

Merge branch 'master' into export-slabh

2010-04-05T02:37:28+00:00

perf, probe-finder: Build fix on Debian

2010-04-02T20:46:26+00:00

Building chokes with:

 In file included from /usr/include/gelf.h:53,
                 from /usr/include/elfutils/libdw.h:53,
                 from util/probe-finder.h:61,
                 from util/probe-finder.c:39:
 /usr/include/libelf.h:98: error: expected specifier-qualifier-list before 'off64_t'
 [...]

Signed-off-by: Borislav Petkov 
Acked-by: Masami Hiramatsu 
LKML-Reference: <20100329164755.GA16034@aftab>
Signed-off-by: Ingo Molnar

perf/scripts: Tuple was set from long in both branches in python_process_event()

2010-04-02T19:32:16+00:00

This is a fix to the signed/unsigned field handling in the
Python scripting engine, based on a patch from Roel Kluin.

Basically, Python wants to use a PyInt (which is internally a
long) if it can i.e. if the value will fit into that type.  If
not, it stores it into a PyLong, which isn't actually a long,
but an arbitrary-precision integer variable.

The code below is similar to to what Python does internally, and
it seems to work as expected on the x86 and x86_64 sytems I
tested it on.

Signed-off-by: Tom Zanussi 
Cc: Arnaldo Carvalho de Melo 
Cc: Roel Kluin 
Cc: Frederic Weisbecker 
Cc: rostedt@goodmis.org
LKML-Reference: <1270184305.6422.10.camel@tropicana>
Signed-off-by: Ingo Molnar

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

2010-03-30T13:02:32+00:00

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo 
Guess-its-ok-by: Christoph Lameter 
Cc: Ingo Molnar 
Cc: Lee Schermerhorn