1. 12 Jul, 2013 33 commits
  2. 10 Jul, 2013 2 commits
    • Ramkumar Ramachandra's avatar
      perf script: Fix broken include in Context.xs · 750ade7e
      Ramkumar Ramachandra authored
      765532c8 (perf script: Finish the rename from trace to script,
      2010-12-23) made a mistake during find-and-replace replacing
      "../../../util/trace-event.h" with "../../../util/script-event.h", a
      non-existent file.  Fix this include.
      Signed-off-by: default avatarRamkumar Ramachandra <artagnon@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1373364033-7918-3-git-send-email-artagnon@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      750ade7e
    • Mike Frysinger's avatar
      perf tools: Fix -ldw/-lelf link test when static linking · d14c4965
      Mike Frysinger authored
      Since libelf sometimes uses libpthread, we have to list that after -lelf
      when someone tries to build statically.  Else things go boom:
      
      Makefile:479: *** No libelf.h/libelf found, please install \
      	libelf-dev/elfutils-libelf-devel.  Stop.
      
      Similarly, the -ldw test fails as it often uses -lz:
      
      Makefile:462: No libdw.h found or old libdw.h found or elfutils is older \
      	than 0.138, disables dwarf support. Please install new elfutils-devel/libdw-dev
      
      And if we add debugging to try-cc, we see:
      + echo '#include <dwarf.h>
      
      int main(void)
      {
              Dwarf *dbg = dwarf_begin(0, DWARF_C_READ);
              return (long)dbg;
      }'
      + i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
      	-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
      	-ldw -lelf -static -lpthread -lrt -lelf -lm -o .24368
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateInit_'
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflate'
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateReset'
      /usr/lib/libdw.a(dwarf_begin_elf.o):function check_section.isra.1: error: undefined reference to 'inflateEnd'
      
      + echo '#include <libelf.h>
      
      int main(void)
      {
              Elf *elf = elf_begin(0, ELF_C_READ, 0);
              return (long)elf;
      }'
      + i686-pc-linux-gnu-gcc -x c - -O2 -pipe -march=atom -mtune=atom -mfpmath=sse -g \
      	-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE \
      	-static -lpthread -lrt -lelf -lm -o .19216
      /usr/lib/libelf.a(elf_begin.o):function file_read_elf: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function __libelf_read_mmaped_file: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function read_file: error: undefined reference to 'pthread_rwlock_init'
      /usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_unlock'
      /usr/lib/libelf.a(elf_begin.o):function lock_dup_elf.8072: error: undefined reference to 'pthread_rwlock_wrlock'
      /usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_rdlock'
      /usr/lib/libelf.a(elf_begin.o):function elf_begin: error: undefined reference to 'pthread_rwlock_unlock'
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1368073064-18276-1-git-send-email-vapier@gentoo.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      d14c4965
  3. 09 Jul, 2013 1 commit
    • Michael Witten's avatar
      perf tools: Revert regression in configuration of Python support · a363a9da
      Michael Witten authored
      Among other things, the following:
      
        commit 31160d7f
        Date:   Tue Jan 8 16:22:36 2013 -0500
        perf tools: Fix GNU make v3.80 compatibility issue
      
      attempts to aid the user by tapping into an existing error message,
      as described in the commit message:
      
        ... Also fix an issue where _get_attempt was called with only
        one argument. This prevented the error message from printing
        the name of the variable that can be used to fix the problem.
      
      or more precisely:
      
        -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
        +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1)))
      
      However, The "missing" argument was in fact missing on purpose; it's
      absence is a signal that the error message should be skipped, because
      the failure would be due to the default value, not any user-supplied
      value.  This can be seen in how `_ge_attempt' uses `gea_err' (in the
      config/utilities.mak file):
      
        _ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2)))
        _gea_warn = $(warning The path '$(1)' is not executable.)
        _gea_err  = $(if $(1),$(error Please set '$(1)' appropriately))
      
      That is, because the argument is no longer missing, the value `$(1)'
      (associated with `_gea_err') always evaluates to true, thus always
      triggering the error condition that is meant to be reserved for
      only the case when a user explicitly supplies an invalid value.
      
      Concretely, the result is a regression in the Makefile's configuration
      of python support; rather than gracefully disable support when the
      relevant executables cannot be found according to default values, the
      build process halts in error as though the user explicitly supplied
      the values.
      
      This new commit simply reverts the offending one-line change.
      Reported-by: default avatarPekka Enberg <penberg@kernel.org>
      Link: http://lkml.kernel.org/r/CAOJsxLHv17Ys3M7P5q25imkUxQW6LE_vABxh1N3Tt7Mv6Ho4iw@mail.gmail.comSigned-off-by: default avatarMichael Witten <mfwitten@gmail.com>
      a363a9da
  4. 08 Jul, 2013 4 commits
    • Robert Richter's avatar
      perf tools: Fix perf version generation · a4147f0f
      Robert Richter authored
      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: default avatarRobert Richter <robert.richter@calxeda.com>
      Link: http://lkml.kernel.org/r/1368006214-12912-1-git-send-email-rric@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      a4147f0f
    • Stephane Eranian's avatar
      perf stat: Fix per-socket output bug for uncore events · 582ec082
      Stephane Eranian authored
      This patch fixes a problem reported by Andi Kleen on perf
      stat when measuring uncore events:
      
       # perf stat --per-socket -e uncore_pcu/event=0x0/ -I1000  -a sleep 2
      
      It would not report counts for the second socket. That was due to a
      cpu mapping bug in print_aggr().
      
      This patch also fixes the socket numbering bug for <not counted>
      events.
      Reported-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Tested-by: default avatarAndi Kleen <ak@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: zheng.z.yan@intel.com
      Link: http://lkml.kernel.org/r/20130705170645.GA32519@quadSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      582ec082
    • Waiman Long's avatar
      perf symbols: Fix vdso list searching · f9ceffb6
      Waiman Long authored
      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: default avatarWaiman Long <Waiman.Long@hp.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: "Chandramouleeswaran, Aswin" <aswin@hp.com>
      Cc: "Norton, Scott J" <scott.norton@hp.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      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: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f9ceffb6
    • Adrian Hunter's avatar
      perf evsel: Fix missing increment in sample parsing · 54bd2692
      Adrian Hunter authored
      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: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1372944040-32690-16-git-send-email-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      54bd2692