1. 26 3月, 2010 1 次提交
  2. 18 3月, 2010 2 次提交
    • Z
      perf events: Change perf parameter --pid to process-wide collection instead of thread-wide · d6d901c2
      Zhang, Yanmin 提交于
      Parameter --pid (or -p) of perf currently means a thread-wide
      collection. For exmaple, if a process whose id is 8888 has 10
      threads, 'perf top -p 8888' just collects the main thread
      statistics. That's misleading. Users are used to attach a whole
      process when debugging a process by gdb. To follow normal usage
      style, the patch change --pid to process-wide collection and add
      --tid (-t) to mean a thread-wide collection.
      
      Usage example is:
      
       # perf top -p 8888
       # perf record -p 8888 -f sleep 10
       # perf stat -p 8888 -f sleep 10
      
      Above commands collect the statistics of all threads of process
      8888.
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Sheng Yang <sheng@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: zhiteng.huang@intel.com
      Cc: Zachary Amsden <zamsden@redhat.com>
      LKML-Reference: <1268922965-14774-3-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d6d901c2
    • Z
      perf record: Enable counters only when kernel is execing subcommand · 46be604b
      Zhang, Yanmin 提交于
      'perf record' starts counters before subcommand is execed, so
      the statistics is not precise because it includes data of some
      preparation steps. I fix it with the patch.
      
      In addition, change the condition to fork/exec subcommand. If
      there is a subcommand parameter, perf always fork/exec it. The
      usage example is:
      
       # perf record -f -a sleep 10
      
      So this command could collect statistics for 10 seconds
      precisely. User still could stop it by CTRL+C. Without the new
      capability, user could only input CTRL+C to stop it without
      precise time clock.
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Sheng Yang <sheng@linux.intel.com>
      Cc: oerg Roedel <joro@8bytes.org>
      Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: <zhiteng.huang@intel.com>
      Cc: Zachary Amsden <zamsden@redhat.com>
      LKML-Reference: <1268922965-14774-2-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      46be604b
  3. 15 3月, 2010 1 次提交
  4. 12 3月, 2010 2 次提交
  5. 11 3月, 2010 1 次提交
    • P
      perf tools: Fix sparse CPU numbering related bugs · a12b51c4
      Paul Mackerras 提交于
      At present, the perf subcommands that do system-wide monitoring
      (perf stat, perf record and perf top) don't work properly unless
      the online cpus are numbered 0, 1, ..., N-1.  These tools ask
      for the number of online cpus with sysconf(_SC_NPROCESSORS_ONLN)
      and then try to create events for cpus 0, 1, ..., N-1.
      
      This creates problems for systems where the online cpus are
      numbered sparsely.  For example, a POWER6 system in
      single-threaded mode (i.e. only running 1 hardware thread per
      core) will have only even-numbered cpus online.
      
      This fixes the problem by reading the /sys/devices/system/cpu/online
      file to find out which cpus are online.  The code that does that is in
      tools/perf/util/cpumap.[ch], and consists of a read_cpu_map()
      function that sets up a cpumap[] array and returns the number of
      online cpus.  If /sys/devices/system/cpu/online can't be read or
      can't be parsed successfully, it falls back to using sysconf to
      ask how many cpus are online and sets up an identity map in cpumap[].
      
      The perf record, perf stat and perf top code then calls
      read_cpu_map() in the system-wide monitoring case (instead of
      sysconf) and uses cpumap[] to get the cpu numbers to pass to
      perf_event_open.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      LKML-Reference: <20100310093609.GA3959@brick.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a12b51c4
  6. 10 3月, 2010 1 次提交
  7. 08 2月, 2010 1 次提交
    • A
      perf record: Fix existing process callgraph symbol · f7e7ee36
      austin_zhang@linux.intel.com 提交于
      When 'perf record -g' a existing process, even with debuginfo
      packages, still cannnot get symbol from 'perf report'.
      
      try:
      
       perf record -g -p `pidof xxx` -f
       perf report
      
          68.26%    :1181           b74870f2  [.] 0x000000b74870f2
                    |
                    |--32.09%-- 0xb73b5b44
                    |          0xb7487102
                    |          0xb748a4e2
                    |          0xb748633d
                    |          0xb73b41cd
                    |          0xb73b4467
                    |          0xb747d531
      
      The reason is: for existing process, in __cmd_record(),
      the pid is 0 rather than the existing process id.
      Signed-off-by: NAustin Zhang <austin_zhang@linux.intel.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <4710.10.255.24.35.1265389362.squirrel@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f7e7ee36
  8. 04 2月, 2010 2 次提交
  9. 03 2月, 2010 1 次提交
    • X
      perf tools: Use O_LARGEFILE to open perf data file · b8f46c5a
      Xiao Guangrong 提交于
      Open perf data file with O_LARGEFILE flag since its size is
      easily larger that 2G.
      
      For example:
      
       # rm -rf perf.data
       # ./perf kmem record sleep 300
      
       [ perf record: Woken up 0 times to write data ]
       [ perf record: Captured and wrote 3142.147 MB perf.data
       (~137282513 samples) ]
      
       # ll -h perf.data
       -rw------- 1 root root 3.1G .....
      Signed-off-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <4B68F32A.9040203@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b8f46c5a
  10. 31 1月, 2010 1 次提交
    • H
      Revert "perf record: Intercept all events" · a8e6f734
      Hitoshi Mitake 提交于
      This reverts commit f5a2c3dc.
      
      This patch is required for making "perf lock rec" work.
      The commit f5a2c3dc changes write_event() of builtin-record.c
      . And changed write_event() sometimes doesn't stop with perf
      lock rec.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <new-submission>
      [ that commit also causes perf record to not be Ctrl-C-able,
        and it's concetually wrong to parse the data at record time
        (unconditionally - even when not needed), as we eventually
        want to be able to do zero-copy recording, at least for
        non-archive recordings.  ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a8e6f734
  11. 29 1月, 2010 1 次提交
  12. 16 1月, 2010 2 次提交
    • A
      perf record: Intercept all events · f5a2c3dc
      Arnaldo Carvalho de Melo 提交于
      The event interception we need to do in 'perf record' to create
      a list of all DSOs in PERF_RECORD_MMAP events wasn't seeing all
      events, make sure that happens by checking size agains
      event_t->header.size.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1263586107-1756-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f5a2c3dc
    • A
      perf record: Encode the domain while synthesizing MMAP events · 18c3daa4
      Arnaldo Carvalho de Melo 提交于
      In the past 'perf record' had to process only userspace MMAP
      events, the ones generated in the kernel, but after we reused
      the MMAP events to encode the module mapings we ended up adding
      them first to the list of userspace DSOs (dsos__user) and to the
      kernel one (dsos__kernel).
      
      Fix this by encoding the header.misc field and then using it,
      like other parts to decide the right DSOs list to insert/find.
      
      The gotcha here is that since the kernel puts zero in .misc,
      which isn't PERF_RECORD_MISC_KERNEL (1 << 1), to differentiate,
      we put 1 in .misc.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1263519930-22803-2-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      18c3daa4
  13. 14 1月, 2010 1 次提交
    • A
      perf tools: Encode kernel module mappings in perf.data · b7cece76
      Arnaldo Carvalho de Melo 提交于
      We were always looking at the running machine /proc/modules,
      even when processing a perf.data file, which only makes sense
      when we're doing 'perf record' and 'perf report' on the same
      machine, and in close sucession, or if we don't use modules at
      all, right Peter? ;-)
      
      Now, at 'perf record' time we read /proc/modules, find the long
      path for modules, and put them as PERF_MMAP events, just like we
      did to encode the reloc reference symbol for vmlinux. Talking
      about that now it is encoded in .pgoff, so that we can use
      .{start,len} to store the address boundaries for the kernel so
      that when we reconstruct the kmaps tree we can do lookups right
      away, without having to fixup the end of the kernel maps like we
      did in the past (and now only in perf record).
      
      One more step in the 'perf archive' direction when we'll finally
      be able to collect data in one machine and analyse in another.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1263396139-4798-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b7cece76
  14. 13 1月, 2010 1 次提交
    • A
      perf tools: Handle relocatable kernels · 56b03f3c
      Arnaldo Carvalho de Melo 提交于
      DSOs don't have this problem because the kernel emits a
      PERF_MMAP for each new executable mapping it performs on
      monitored threads.
      
      To fix the kernel case we simulate the same behaviour, by having
      'perf record' to synthesize a PERF_MMAP for the kernel, encoded
      like this:
      
      [root@doppio ~]# perf record -a -f sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.344 MB perf.data (~15038 samples) ]
      [root@doppio ~]# perf report -D | head -10
      
      0xd0 [0x40]: event: 1
      .
      . ... raw event: size 64 bytes
      .  0000:  01 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 ......@........
      .  0010:  00 00 00 81 ff ff ff ff 00 00 00 00 00 00 00 00 ...............
      .  0020:  00 00 00 00 00 00 00 00 5b 6b 65 72 6e 65 6c 2e ........  [kernel
      .  0030:  6b 61 6c 6c 73 79 6d 73 2e 5f 74 65 78 74 5d 00  kallsyms._text]
      .  0xd0
      [0x40]: PERF_RECORD_MMAP 0/0: [0xffffffff81000000((nil)) @ (nil)]: [kernel.kallsyms._text]
      
      I.e. we identify such event as having:
      
       .pid      = 0
       .filename = [kernel.kallsyms.REFNAME]
       .start    = REFNAME addr in /proc/kallsyms at 'perf record' time
      
      and use now a hardcoded value of '.text' for REFNAME.
      
      Then, later, in 'perf report', if there are any kernel hits and
      thus we need to resolve kernel symbols, we search for REFNAME
      and if its address changed, relocation happened and we thus must
      change the kernel mapping routines to one that uses .pgoff as
      the relocation to apply.
      
      This way we use the same mechanism used for the other DSOs and
      don't have to do a two pass in all the kernel symbols.
      Reported-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      LKML-Reference: <1262717431-1246-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      56b03f3c
  15. 28 12月, 2009 1 次提交
  16. 17 12月, 2009 2 次提交
  17. 16 12月, 2009 2 次提交
  18. 15 12月, 2009 1 次提交
  19. 14 12月, 2009 2 次提交
    • A
      perf session: Move kmaps to perf_session · 4aa65636
      Arnaldo Carvalho de Melo 提交于
      There is still some more work to do to disentangle map creation
      from DSO loading, but this happens only for the kernel, and for
      the early adopters of perf diff, where this disentanglement
      matters most, we'll be testing different kernels, so no problem
      here.
      
      Further clarification: right now we create the kernel maps for
      the various modules and discontiguous kernel text maps when
      loading the DSO, we should do it as a two step process, first
      creating the maps, for multiple mappings with the same DSO
      store, then doing the dso load just once, for the first hit on
      one of the maps sharing this DSO backing store.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1260741029-4430-6-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4aa65636
    • A
      perf session: Pass the perf_session to the event handling operations · d8f66248
      Arnaldo Carvalho de Melo 提交于
      They will need it to get the right threads list, etc.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1260741029-4430-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d8f66248
  20. 12 12月, 2009 1 次提交
    • A
      perf tools: Introduce perf_session class · 94c744b6
      Arnaldo Carvalho de Melo 提交于
      That does all the initialization boilerplate, opening the file,
      reading the header, checking if it is valid, etc.
      
      And that will as well have the threads list, kmap (now) global
      variable, etc, so that we can handle two (or more) perf.data files
      describing sessions to compare.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1260573842-19720-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      94c744b6
  21. 23 11月, 2009 1 次提交
  22. 20 11月, 2009 2 次提交
  23. 17 11月, 2009 4 次提交
  24. 11 11月, 2009 3 次提交
  25. 09 11月, 2009 1 次提交
    • P
      perf tools: Fix permission checks · c10edee2
      Pekka Enberg 提交于
      The perf_event_open() system call returns EACCES if the user is
      not root which results in a very confusing error message:
      
        $ perf record -A -a -f
      
          Error: perfcounter syscall returned with -1 (Permission denied)
      
          Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
      
      It turns out that's because perf tools are checking only for
      EPERM. Fix that up to get a much better error message:
      
        $ perf record -A -a -f
          Fatal: Permission error - are you root?
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <1257696066-4046-1-git-send-email-penberg@cs.helsinki.fi>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c10edee2
  26. 08 11月, 2009 1 次提交
    • A
      perf symbols: Use the buildids if present · 8d06367f
      Arnaldo Carvalho de Melo 提交于
      With this change 'perf record' will intercept PERF_RECORD_MMAP
      calls, creating a linked list of DSOs, then when the session
      finishes, it will traverse this list and read the buildids,
      stashing them at the end of the file and will set up a new
      feature bit in the header bitmask.
      
      'perf report' will then notice this feature and populate the
      'dsos' list and set the build ids.
      
      When reading the symtabs it will refuse to load from a file that
      doesn't have the same build id. This improves the
      reliability of the profiler output, as symbols and profiling
      data is more guaranteed to match.
      
      Example:
      
       [root@doppio ~]# perf report | head
       /home/acme/bin/perf with build id b1ea544ac3746e7538972548a09aadecc5753868 not found, continuing without symbols
        # Samples: 2621434559
        #
        # Overhead          Command                  Shared Object  Symbol
        # ........  ...............  .............................  ......
        #
             7.91%             init  [kernel]        [k] read_hpet
             7.64%             init  [kernel]        [k] mwait_idle_with_hints
             7.60%          swapper  [kernel]        [k] read_hpet
             7.60%          swapper  [kernel]        [k] mwait_idle_with_hints
             3.65%             init  [kernel]        [k] 0xffffffffa02339d9
      [root@doppio ~]#
      
      In this case the 'perf' binary was an older one, vanished,
      so its symbols probably wouldn't match or would cause subtly
      different (and misleading) output.
      
      Next patches will support the kernel as well, reading the build
      id notes for it and the modules from /sys.
      
      Another patch should also introduce a new plumbing command:
      
      'perf list-buildids'
      
      that will then be used in porcelain that is distro specific to
      fetch -debuginfo packages where such buildids are present. This
      will in turn allow for one to run 'perf record' in one machine
      and 'perf report' in another.
      
      Future work on having the buildid sent directly from the kernel
      in the PERF_RECORD_MMAP event is needed to close races, as the
      DSO can be changed during a 'perf record' session, but this
      patch at least helps with non-corner cases and current/older
      kernels.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      LKML-Reference: <1257367843-26224-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d06367f
  27. 27 10月, 2009 1 次提交
    • A
      perf tools: Generalize event synthesizing routines · 234fbbf5
      Arnaldo Carvalho de Melo 提交于
      Because we will need it in 'perf top' to support userspace
      symbols for existing threads.
      
      Now we pass a callback that will receive the synthesized event
      and then write it to the output file in 'perf record' and in the
      upcoming patch for 'perf top' we will just immediatelly create
      the in memory representation of threads and maps.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Mike Galbraith <efault@gmx.de>
      LKML-Reference: <1256592199-9608-2-git-send-email-acme@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      234fbbf5