1. 28 10月, 2013 1 次提交
  2. 18 10月, 2013 1 次提交
    • S
      perf: Disable PERF_RECORD_MMAP2 support · 3090ffb5
      Stephane Eranian 提交于
      For now, we disable the extended MMAP record support (MMAP2).
      
      We have identified cases where it would not report the correct mapping
      information, clone(VM_CLONE) but with separate pids.  We will revisit
      the support once we find a solution for this case.
      
      The patch changes the kernel to return EINVAL if attr->mmap2 is set. The
      patch also modifies the perf tool to use regular PERF_RECORD_MMAP for
      synthetic events and it also prevents the tool from requesting
      attr->mmap2 mode because the kernel would reject it.
      
      The support will be revisited once the kenrel interface is updated.
      
      In V2, we reduce the patch to the strict minimum.
      
      In V3, we avoid calling perf_event_open() with mmap2 set because we know
      it will fail and require fallback retry.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20131017173215.GA8820@quadSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3090ffb5
  3. 11 9月, 2013 1 次提交
    • S
      perf tools: Add attr->mmap2 support · 5c5e854b
      Stephane Eranian 提交于
      This patch adds support for the new PERF_RECORD_MMAP2 record type
      exposed by the kernel. This is an extended PERF_RECORD_MMAP record.
      
      It adds for each file-backed mapping the device major, minor number and
      the inode number and generation.
      
      This triplet uniquely identifies the source of a file-backed mapping. It
      can be used to detect identical virtual mappings between processes, for
      instance.
      
      The patch will prefer MMAP2 over MMAP.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.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>
      Link: http://lkml.kernel.org/r/1377079825-19057-3-git-send-email-eranian@google.com
      [ Cope with 314add6b "Change machine__findnew_thread() to set thread pid",
        fix 'perf test' regression test entry affected,
        use perf_missing_features.mmap2 to fallback to not using .mmap2 in older kernels,
        so that new tools can work with kernels where this feature is not present ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c5e854b
  4. 30 8月, 2013 1 次提交
  5. 29 8月, 2013 1 次提交
  6. 12 8月, 2013 3 次提交
  7. 08 8月, 2013 1 次提交
  8. 13 7月, 2013 1 次提交
  9. 30 1月, 2013 1 次提交
  10. 15 11月, 2012 1 次提交
  11. 25 10月, 2012 1 次提交
  12. 07 10月, 2012 2 次提交
    • A
      perf machine: Carve up event processing specific from perf_tool · b0a7d1a0
      Arnaldo Carvalho de Melo 提交于
      The perf_tool vtable expects methods that receive perf_tool and
      perf_sample entries, but for tools not interested in doing any special
      processing on non PERF_RECORD_SAMPLE events, like 'perf top', and for
      those not using perf_session, like 'perf trace', they were using
      perf_event__process passing tool and sample paramenters that were just
      not used.
      
      Provide 'machine' methods for this purpose and make the perf_event
      ones use them.
      
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      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/n/tip-ot9cc6mt025o8kbngzckcrx9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b0a7d1a0
    • A
      perf event: No need to create a thread when handling PERF_RECORD_EXIT · f62d3f0f
      Arnaldo Carvalho de Melo 提交于
      When we were processing a PERF_RECORD_EXIT event we first used
      machine__findnew_thread for both the thread exiting and for its parent,
      only to use just the thread struct associated with the one exiting, and
      to just delete it.
      
      If it existed, i.e. not created at this very moment in
      machine__findnew_thread, it will be moved to the machine->dead_threads
      linked list, because we may have hist_entries pointing to it, but if it
      was created just do be deleted, it will just sit there with no
      references at all.
      
      Use the new machine__find_thread() method so that if it is not there, we
      don't create it.
      
      As a bonus the parent thread will also not be created at this point.
      
      Create process_fork() and process_exit() helpers to use this and make
      the builtins use it instead of the generic process_task(), ditched by
      this patch.
      
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      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/n/tip-z7n2y98ebjyrvmytaope4vdl@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f62d3f0f
  13. 18 9月, 2012 1 次提交
  14. 11 9月, 2012 2 次提交
    • I
      perf tools: Use __maybe_used for unused variables · 1d037ca1
      Irina Tirdea 提交于
      perf defines both __used and __unused variables to use for marking
      unused variables. The variable __used is defined to
      __attribute__((__unused__)), which contradicts the kernel definition to
      __attribute__((__used__)) for new gcc versions. On Android, __used is
      also defined in system headers and this leads to warnings like: warning:
      '__used__' attribute ignored
      
      __unused is not defined in the kernel and is not a standard definition.
      If __unused is included everywhere instead of __used, this leads to
      conflicts with glibc headers, since glibc has a variables with this name
      in its headers.
      
      The best approach is to use __maybe_unused, the definition used in the
      kernel for __attribute__((unused)). In this way there is only one
      definition in perf sources (instead of 2 definitions that point to the
      same thing: __used and __unused) and it works on both Linux and Android.
      This patch simply replaces all instances of __used and __unused with
      __maybe_unused.
      Signed-off-by: NIrina Tirdea <irina.tirdea@intel.com>
      Acked-by: NPekka Enberg <penberg@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1347315303-29906-7-git-send-email-irina.tirdea@intel.com
      [ committer note: fixed up conflict with a116e05d in builtin-sched.c ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1d037ca1
    • I
      perf tools: fix ALIGN redefinition in system headers · 9ac3e487
      Irina Tirdea 提交于
      On some systems (e.g. Android), ALIGN is defined in system headers as
      ALIGN(p).  The definition of ALIGN used in perf takes 2 parameters:
      ALIGN(x,a).  This leads to redefinition conflicts.
      
      Redefinition error on Android:
      In file included from util/include/linux/list.h:1:0,
      from util/callchain.h:5,
      from util/hist.h:6,
      from util/session.h:4,
      from util/build-id.h:4,
      from util/annotate.c:11:
      util/include/linux/kernel.h:11:0: error: "ALIGN" redefined [-Werror]
      bionic/libc/include/sys/param.h:38:0: note: this is the location of
      the previous definition
      
      Conflics with system defined ALIGN in Android:
      util/event.c: In function 'perf_event__synthesize_comm':
      util/event.c:115:32: error: macro "ALIGN" passed 2 arguments, but takes just 1
      util/event.c:115:9: error: 'ALIGN' undeclared (first use in this function)
      util/event.c:115:9: note: each undeclared identifier is reported only once for
      each function it appears in
      
      In order to avoid this redefinition, ALIGN is renamed to PERF_ALIGN.
      Signed-off-by: NIrina Tirdea <irina.tirdea@intel.com>
      Acked-by: NPekka Enberg <penberg@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Irina Tirdea <irina.tirdea@intel.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1347315303-29906-5-git-send-email-irina.tirdea@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9ac3e487
  15. 06 9月, 2012 1 次提交
  16. 14 8月, 2012 1 次提交
    • C
      perf symbols: Remove unused 'end' arg in kallsyms parse cb · 82151520
      Cody P Schafer 提交于
      kallsyms__parse() takes a callback that is called on every discovered
      symbol. As /proc/kallsyms does not supply symbol sizes, the callback was
      simply called with end=start, faking the symbol size to 1.
      
      All of the callbacks (there are 2) used in calls to kallsyms__parse()
      are _only_ used as callbacks for kallsyms__parse().
      
      Given that kallsyms__parse() lacks real information about what
      end/length should be, don't make up a length in kallsyms__parse().
      Instead have the callbacks handle guessing the length.
      
      Also relocate a comment regarding symbol creation to the callback which
      does symbol creation (kallsyms__parse() is not in general used to create
      symbols).
      Signed-off-by: NCody P Schafer <cody@linux.vnet.ibm.com>
      Cc: David Hansen <dave@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Matt Hellsley <matthltc@us.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1344637382-22789-3-git-send-email-cody@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      82151520
  17. 01 3月, 2012 1 次提交
  18. 07 2月, 2012 1 次提交
    • J
      perf tools: Fix prefix matching for kernel maps · bf32c9eb
      Jiri Olsa 提交于
      In some perf ancient versions we used '[kernel.kallsyms._text]' as the
      name for the kernel map.
      
      This got changed with commit:
        perf: 'perf kvm' tool for monitoring guest performance from host
        commit a1645ce1
        Author: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
      
      and we started to use following name '[kernel.kallsyms]_text'.
      
      This name change is important for the report code dealing with ancient
      perf data. When processing the kernel map event, we need to recognize
      the old naming (dont match the last ']') and initialize the kernel map
      correctly.
      
      The subsequent call to maps__set_kallsyms_ref_reloc_sym deals with the
      superfluous ']' to get correct symbol name.
      
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1328461865-6127-1-git-send-email-jolsa@redhat.comSigned-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bf32c9eb
  19. 24 12月, 2011 2 次提交
    • D
      perf tools: Look up thread names for system wide profiling · f5faf726
      David Ahern 提交于
      This handles multithreaded processes with named threads when doing
      system wide profiling: the comm for each thread is looked up allowing
      them to be different from the thread group leader.
      
      v2:
      - fixed sizeof arg to perf_event__get_comm_tgid
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1324578603-12762-3-git-send-email-dsahern@gmail.comSigned-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f5faf726
    • D
      perf tools: Fix comm for processes with named threads · defd8d38
      David Ahern 提交于
      perf does not properly handle monitoring of processes with named threads.
      For example:
      
      $ ps -C myapp -L
        PID   LWP TTY          TIME CMD
      25118 25118 ?        00:00:00 myapp
      25118 25119 ?        00:00:00 myapp:worker
      
      perf record -e cs -c 1 -fo /tmp/perf.data -p 25118 -- sleep 10
      perf report --stdio -i /tmp/perf.data
         100.00%  myapp:worker  [kernel.kallsyms]  [k] perf_event_task_sched_out
      
      The process name is set to the name of the last thread it finds for the
      process.
      
      The Problem:
      perf-top and perf-record both create a thread_map of threads to be
      monitored. That map is used in perf_event__synthesize_thread_map which
      loops over the entries in thread_map and calls __event__synthesize_thread
      to generate COMM and MMAP events.
      
      __event__synthesize_thread calls perf_event__synthesize_comm which opens
      /proc/pid/status, reads the name of the task and its thread group id.
      That's all fine. The problem is that it then reads /proc/pid/task and
      generates COMM events for each task it finds - but using the name found
      in /proc/pid/status where pid is the thread of interest.
      
      The end result (looping over thread_map + synthesizing comm events for
      each thread each time) means the name of the last thread processed sets
      the name for all threads in the process - which is not good for
      multithreaded processes with named threads.
      
      The Fix:
      perf_event__synthesize_comm has an input argument (full) that decides
      whether to process task entries for each pid it is passed. It currently
      never set to 0 (perf_event__synthesize_comm has a single caller and it
      always passes the value 1). Let's fix that.
      
      Add the full input argument to __event__synthesize_thread which passes
      it to perf_event__synthesize_comm. For thread/process monitoring set full
      to 0 which means COMM and MMAP events are only generated for the pid
      passed to it. For system wide monitoring set full to 1 so that COMM events
      are generated for all threads in a process.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1324578603-12762-2-git-send-email-dsahern@gmail.comSigned-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      defd8d38
  20. 20 12月, 2011 1 次提交
  21. 02 12月, 2011 1 次提交
  22. 28 11月, 2011 3 次提交
  23. 24 9月, 2011 1 次提交
  24. 03 6月, 2011 1 次提交
    • A
      perf evlist: Don't die if sample_{id_all|type} is invalid · 56722381
      Arnaldo Carvalho de Melo 提交于
      Fixes two more cases where the python binding would not load:
      
      . Not finding die(), which it shouldn't anyway, not good to just stop the
        world because some particular perf.data file is invalid, just propagate
        the error to the caller.
      
      . Not finding perf_sample_size: fix it by moving it from event.c to evsel,
        where it belongs, as most cases are moving to operate on an evsel object.o
      
      One of the fixed problems:
      
      [root@emilia ~]# python
      >>> import perf
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      ImportError: /home/acme/git/build/perf/python/perf.so: undefined symbol: perf_sample_size
      >>>
      [root@emilia ~]#
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-1hkj7b2cvgbfnoizsekjb6c9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      56722381
  25. 02 6月, 2011 1 次提交
    • A
      perf evlist: Don't die if sample_{id_all|type} is invalid · c2a70653
      Arnaldo Carvalho de Melo 提交于
      Fixes two more cases where the python binding would not load:
      
      . Not finding die(), which it shouldn't anyway, not good to just stop the
        world because some particular perf.data file is invalid, just propagate
        the error to the caller.
      
      . Not finding perf_sample_size: fix it by moving it from event.c to evsel,
        where it belongs, as most cases are moving to operate on an evsel object.o
      
      One of the fixed problems:
      
      [root@emilia ~]# python
      >>> import perf
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      ImportError: /home/acme/git/build/perf/python/perf.so: undefined symbol: perf_sample_size
      >>>
      [root@emilia ~]#
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-1hkj7b2cvgbfnoizsekjb6c9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c2a70653
  26. 26 5月, 2011 1 次提交
    • A
      perf symbols: Handle /proc/sys/kernel/kptr_restrict · ec80fde7
      Arnaldo Carvalho de Melo 提交于
      Perf uses /proc/modules to figure out where kernel modules are loaded.
      
      With the advent of kptr_restrict, non root users get zeroes for all module
      start addresses.
      
      So check if kptr_restrict is non zero and don't generate the syntethic
      PERF_RECORD_MMAP events for them.
      
      Warn the user about it in perf record and in perf report.
      
      In perf report the reference relocation symbol being zero means that
      kptr_restrict was set, thus /proc/kallsyms has only zeroed addresses, so don't
      use it to fixup symbol addresses when using a valid kallsyms (in the buildid
      cache) or vmlinux (in the vmlinux path) build-id located automatically or
      specified by the user.
      
      Provide an explanation about it in 'perf report' if kernel samples were taken,
      checking if a suitable vmlinux or kallsyms was found/specified.
      
      Restricted /proc/kallsyms don't go to the buildid cache anymore.
      
      Example:
      
       [acme@emilia ~]$ perf record -F 100000 sleep 1
      
       WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check
       /proc/sys/kernel/kptr_restrict.
      
       Samples in kernel functions may not be resolved if a suitable vmlinux file is
       not found in the buildid cache or in the vmlinux path.
      
       Samples in kernel modules won't be resolved at all.
      
       If some relocation was applied (e.g. kexec) symbols may be misresolved even
       with a suitable vmlinux or kallsyms file.
      
       [ perf record: Woken up 1 times to write data ]
       [ perf record: Captured and wrote 0.005 MB perf.data (~231 samples) ]
       [acme@emilia ~]$
      
       [acme@emilia ~]$ perf report --stdio
       Kernel address maps (/proc/{kallsyms,modules}) were restricted,
       check /proc/sys/kernel/kptr_restrict before running 'perf record'.
      
       If some relocation was applied (e.g. kexec) symbols may be misresolved.
      
       Samples in kernel modules can't be resolved as well.
      
       # Events: 13  cycles
       #
       # Overhead  Command      Shared Object                 Symbol
       # ........  .......  .................  .....................
       #
          20.24%    sleep  [kernel.kallsyms]  [k] page_fault
          20.04%    sleep  [kernel.kallsyms]  [k] filemap_fault
          19.78%    sleep  [kernel.kallsyms]  [k] __lru_cache_add
          19.69%    sleep  ld-2.12.so         [.] memcpy
          14.71%    sleep  [kernel.kallsyms]  [k] dput
           4.70%    sleep  [kernel.kallsyms]  [k] flush_signal_handlers
           0.73%    sleep  [kernel.kallsyms]  [k] perf_event_comm
           0.11%    sleep  [kernel.kallsyms]  [k] native_write_msr_safe
      
       #
       # (For a higher level overview, try: perf report --sort comm,dso)
       #
       [acme@emilia ~]$
      
      This is because it found a suitable vmlinux (build-id checked) in
      /lib/modules/2.6.39-rc7+/build/vmlinux (use -v in perf report to see the long
      file name).
      
      If we remove that file from the vmlinux path:
      
       [root@emilia ~]# mv /lib/modules/2.6.39-rc7+/build/vmlinux \
      		     /lib/modules/2.6.39-rc7+/build/vmlinux.OFF
       [acme@emilia ~]$ perf report --stdio
       [kernel.kallsyms] with build id 57298cdbe0131f6871667ec0eaab4804dcf6f562
       not found, continuing without symbols
      
       Kernel address maps (/proc/{kallsyms,modules}) were restricted, check
       /proc/sys/kernel/kptr_restrict before running 'perf record'.
      
       As no suitable kallsyms nor vmlinux was found, kernel samples can't be
       resolved.
      
       Samples in kernel modules can't be resolved as well.
      
       # Events: 13  cycles
       #
       # Overhead  Command      Shared Object  Symbol
       # ........  .......  .................  ......
       #
          80.31%    sleep  [kernel.kallsyms]  [k] 0xffffffff8103425a
          19.69%    sleep  ld-2.12.so         [.] memcpy
      
       #
       # (For a higher level overview, try: perf report --sort comm,dso)
       #
       [acme@emilia ~]$
      Reported-by: NStephane Eranian <eranian@google.com>
      Suggested-by: NDavid Miller <davem@davemloft.net>
      Cc: Dave Jones <davej@redhat.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Kees Cook <kees.cook@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Link: http://lkml.kernel.org/n/tip-mt512joaxxbhhp1odop04yit@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ec80fde7
  27. 24 5月, 2011 1 次提交
  28. 23 5月, 2011 1 次提交
  29. 22 5月, 2011 1 次提交
  30. 29 3月, 2011 1 次提交
    • A
      perf symbols: Fix vsyscall symbol lookup · 6c6804fb
      Andrew Lutomirski 提交于
      Perf can't currently trace into the vsyscall page.  It looks like it was
      meant to work.
      
      Tested on 2.6.38 and today's -git.
      
      The bug is easy to reproduce.  Compile this:
      
      int main()
      {
      	int i;
      	struct timespec t;
      	for(i = 0; i < 10000000; i++)
      		clock_gettime(CLOCK_MONOTONIC, &t);
      	return 0;
      }
      
      and run it through perf record; perf report.  The top entry shows
      "[unknown]" and you can't zoom in.
      
      It looks like there are two issues.  The first is a that a test for user
      mode executing in kernel space is backwards.  (That's the first hunk
      below).  The second (I think) is that something's wrong with the code
      that generates lots of little struct dso objects for different sections
      -- when it runs on vmlinux it results in bogus long_name values which
      cause objdump to fail.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LPU-Reference: <AANLkTikxSw5+wJZUWNz++nL7mgivCh_Zf=2Kq6=f9Ce_@mail.gmail.com>
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6c6804fb
  31. 06 3月, 2011 1 次提交
    • A
      perf hists: Remove needless global col lenght calcs · d7603d51
      Arnaldo Carvalho de Melo 提交于
      To support multiple events we need to do these calcs per 'struct hists'
      instance, and it turns out we already do that at:
      
      	__hists__add_entry
      		hists__inc_nr_entries
      			hists__calc_col_len
      
      for all the unfiltered hist_entry instances we stash in the rb tree, so
      trow away the dead code.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d7603d51
  32. 10 2月, 2011 1 次提交
    • A
      perf tools: Fix thread_map event synthesizing in top and record · 401b8e13
      Arnaldo Carvalho de Melo 提交于
      Jeff Moyer reported these messages:
      
        Warning:  ... trying to fall back to cpu-clock-ticks
      
      couldn't open /proc/-1/status
      couldn't open /proc/-1/maps
      [ls output]
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.008 MB perf.data (~363 samples) ]
      
      That lead me and David Ahern to see that something was fishy on the thread
      synthesizing routines, at least for the case where the workload is started
      from 'perf record', as -1 is the default for target_tid in 'perf record --tid'
      parameter, so somehow we were trying to synthesize the PERF_RECORD_MMAP and
      PERF_RECORD_COMM events for the thread -1, a bug.
      
      So I investigated this and noticed that when we introduced support for
      recording a process and its threads using --pid some bugs were introduced and
      that the way to fix it was to instead of passing the target_tid to the event
      synthesizing routines we should better pass the thread_map that has the list of
      threads for a --pid or just the single thread for a --tid.
      
      Checked in the following ways:
      
      On a 8-way machine run cyclictest:
      
      [root@emilia ~]# perf record cyclictest -a -t -n -p99 -i100 -d50
      policy: fifo: loadavg: 0.00 0.13 0.31 2/139 28798
      
      T: 0 (28791) P:99 I:100 C:  25072 Min:      4 Act:    5 Avg:    6 Max:     122
      T: 1 (28792) P:98 I:150 C:  16715 Min:      4 Act:    6 Avg:    5 Max:      27
      T: 2 (28793) P:97 I:200 C:  12534 Min:      4 Act:    5 Avg:    4 Max:       8
      T: 3 (28794) P:96 I:250 C:  10028 Min:      4 Act:    5 Avg:    5 Max:      96
      T: 4 (28795) P:95 I:300 C:   8357 Min:      5 Act:    6 Avg:    5 Max:      12
      T: 5 (28796) P:94 I:350 C:   7163 Min:      5 Act:    6 Avg:    5 Max:      12
      T: 6 (28797) P:93 I:400 C:   6267 Min:      4 Act:    5 Avg:    5 Max:       9
      T: 7 (28798) P:92 I:450 C:   5571 Min:      4 Act:    5 Avg:    5 Max:       9
      ^C[ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.108 MB perf.data (~4719 samples) ]
      
      [root@emilia ~]#
      
      This will create one extra thread per CPU:
      
      [root@emilia ~]# tuna -t cyclictest -CP
                            thread       ctxt_switches
          pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       28825   OTHER     0     0xff      2169          671      cyclictest
        28832   FIFO    93        6     52338            1      cyclictest
        28833   FIFO    92        7     46524            1      cyclictest
        28826   FIFO    99        0    209360            1      cyclictest
        28827   FIFO    98        1    139577            1      cyclictest
        28828   FIFO    97        2    104686            0      cyclictest
        28829   FIFO    96        3     83751            1      cyclictest
        28830   FIFO    95        4     69794            1      cyclictest
        28831   FIFO    94        5     59825            1      cyclictest
      [root@emilia ~]#
      
      So we should expect only samples for the above 9 threads when using the
      --dump-raw-trace|-D perf report switch to look at the column with the tid:
      
      [root@emilia ~]# perf report -D | grep RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort | uniq -c
          629 28825
          110 28826
          491 28827
          308 28828
          198 28829
          621 28830
          225 28831
          203 28832
           89 28833
      [root@emilia ~]#
      
      So for workloads started by 'perf record' seems to work, now for existing workloads,
      just run cyclictest first, without 'perf record':
      
      [root@emilia ~]# tuna -t cyclictest -CP
                            thread       ctxt_switches
          pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       28859   OTHER     0     0xff       594          200      cyclictest
        28864   FIFO    95        4     16587            1      cyclictest
        28865   FIFO    94        5     14219            1      cyclictest
        28866   FIFO    93        6     12443            0      cyclictest
        28867   FIFO    92        7     11062            1      cyclictest
        28860   FIFO    99        0     49779            1      cyclictest
        28861   FIFO    98        1     33190            1      cyclictest
        28862   FIFO    97        2     24895            1      cyclictest
        28863   FIFO    96        3     19918            1      cyclictest
      [root@emilia ~]#
      
      and then later did:
      
      [root@emilia ~]# perf record --pid 28859 sleep 3
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.027 MB perf.data (~1195 samples) ]
      [root@emilia ~]#
      
      To collect 3 seconds worth of samples for pid 28859 and its children:
      
      [root@emilia ~]# perf report -D | grep RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort | uniq -c
           15 28859
           33 28860
           19 28861
           13 28862
           13 28863
           10 28864
           11 28865
            9 28866
          255 28867
      [root@emilia ~]#
      
      Works, last thing is to check if looking at just one of those threads also works:
      
      [root@emilia ~]# perf record --tid 28866 sleep 3
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.006 MB perf.data (~242 samples) ]
      [root@emilia ~]# perf report -D | grep RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort | uniq -c
            3 28866
      [root@emilia ~]#
      
      Works too.
      Reported-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      401b8e13
  33. 30 1月, 2011 1 次提交