1. 16 12月, 2009 2 次提交
    • A
      perf diff: Use perf_session__fprintf_hists just like 'perf record' · c351c281
      Arnaldo Carvalho de Melo 提交于
      That means that almost everything you can do with 'perf report'
      can be done with 'perf diff', for instance:
      
      $ perf record -f find / > /dev/null
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.062 MB perf.data (~2699
      samples) ] $ perf record -f find / > /dev/null
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.062 MB perf.data (~2687
      samples) ] perf diff | head -8
           9.02%     +1.00%     find  libc-2.10.1.so               [.] _IO_vfprintf_internal
           2.91%     -1.00%     find  [kernel]                     [k] __kmalloc
           2.85%     -1.00%     find  [kernel]                     [k] ext4_htree_store_dirent
           1.99%     -1.00%     find  [kernel]                     [k] _atomic_dec_and_lock
           2.44%                find  [kernel]                     [k] half_md4_transform
      $
      
      So if you want to zoom into libc:
      
      $ perf diff --dsos libc-2.10.1.so | head -8
          37.34%                find  [.] _IO_vfprintf_internal
          10.34%                find  [.] __GI_memmove
           8.25%     +2.00%     find  [.] _int_malloc
           5.07%     -1.00%     find  [.] __GI_mempcpy
           7.62%     +2.00%     find  [.] _int_free
      $
      
      And if there were multiple commands using libc, it is also
      possible to aggregate them all by using --sort symbol:
      
      $ perf diff --dsos libc-2.10.1.so --sort symbol | head -8
          37.34%             [.] _IO_vfprintf_internal
          10.34%             [.] __GI_memmove
           8.25%     +2.00%  [.] _int_malloc
           5.07%     -1.00%  [.] __GI_mempcpy
           7.62%     +2.00%  [.] _int_free
      $
      
      The displacement column now is off by default, to use it:
      
      perf diff -m --dsos libc-2.10.1.so --sort symbol | head -8
          37.34%                   [.] _IO_vfprintf_internal
          10.34%                   [.] __GI_memmove
           8.25%     +2.00%        [.] _int_malloc
           5.07%     -1.00%    +2  [.] __GI_mempcpy
           7.62%     +2.00%    -1  [.] _int_free
      $
      
      Using -t/--field-separator can be used for scripting:
      
      $ perf diff -t, -m --dsos libc-2.10.1.so --sort symbol | head -8
      37.34, , ,[.] _IO_vfprintf_internal
      10.34, , ,[.] __GI_memmove
      8.25,+2.00%, ,[.] _int_malloc
      5.07,-1.00%,  +2,[.] __GI_mempcpy
      7.62,+2.00%,  -1,[.] _int_free
      6.99,+1.00%,  -1,[.] _IO_new_file_xsputn
      1.89,-2.00%,  +4,[.] __readdir64
      $
      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: <1260978567-550-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c351c281
    • A
      perf tools: Move hist entries printing routines from perf report · 4ecf84d0
      Arnaldo Carvalho de Melo 提交于
      Will be used in other tools such as 'perf diff'.
      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: <1260973631-28035-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4ecf84d0
  2. 14 12月, 2009 2 次提交
  3. 28 11月, 2009 1 次提交
    • A
      perf tools: Consolidate symbol resolving across all tools · 1ed091c4
      Arnaldo Carvalho de Melo 提交于
      Now we have a very high level routine for simple tools to
      process IP sample events:
      
      	int event__preprocess_sample(const event_t *self,
      				     struct addr_location *al,
      				     symbol_filter_t filter)
      
      It receives the event itself and will insert new threads in the
      global threads list and resolve the map and symbol, filling all
      this info into the new addr_location struct, so that tools like
      annotate and report can further process the event by creating
      hist_entries in their specific way (with or without callgraphs,
      etc).
      
      It in turn uses the new next layer function:
      
      	void thread__find_addr_location(struct thread *self, u8 cpumode,
      					enum map_type type, u64 addr,
      					struct addr_location *al,
      					symbol_filter_t filter)
      
      This one will, given a thread (userspace or the kernel kthread
      one), will find the given type (MAP__FUNCTION now, MAP__VARIABLE
      too in the near future) at the given cpumode, taking vdsos into
      account (userspace hit, but kernel symbol) and will fill all
      these details in the addr_location given.
      
      Tools that need a more compact API for plain function
      resolution, like 'kmem', can use this other one:
      
      	struct symbol *thread__find_function(struct thread *self, u64 addr,
      					     symbol_filter_t filter)
      
      So, to resolve a kernel symbol, that is all the 'kmem' tool
      needs, its just a matter of calling:
      
      	sym = thread__find_function(kthread, addr, NULL);
      
      The 'filter' parameter is needed because we do lazy
      parsing/loading of ELF symtabs or /proc/kallsyms.
      
      With this we remove more code duplication all around, which is
      always good, huh? :-)
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1259346563-12568-12-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1ed091c4
  4. 03 10月, 2009 1 次提交
  5. 30 9月, 2009 1 次提交