1. 15 12月, 2009 1 次提交
  2. 14 12月, 2009 4 次提交
  3. 12 12月, 2009 1 次提交
    • A
      perf symbols: Rename kthreads to kmaps, using another abstraction for it · 9958e1f0
      Arnaldo Carvalho de Melo 提交于
      Using a struct thread instance just to hold the kernel space maps
      (vmlinux + modules) is overkill and confuses people trying to
      understand the perf symbols abstractions.
      
      The kernel maps are really present in all threads, i.e. the kernel
      is a library, not a separate thread.
      
      So introduce the 'map_groups' abstraction and use it for the kernel
      maps, now in the kmaps global variable.
      
      It, in turn, will move, together with the threads list to the
      perf_file abstraction, so that we can support multiple perf_file
      instances, needed by perf diff.
      
      Brainstormed-with: Eduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Eduardo Habkost <ehabkost@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: <1260550239-5372-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9958e1f0
  4. 07 12月, 2009 1 次提交
    • O
      perf: Make common SAMPLE_EVENT parser · 180f95e2
      OGAWA Hirofumi 提交于
      Currently, sample event data is parsed for each commands, and it
      is assuming that the data is not including other data. (E.g.
      timechart, trace, etc. can't parse the event if it has
      PERF_SAMPLE_CALLCHAIN)
      
      So, even if we record the superset data for multiple commands at
      a time, commands can't parse. etc.
      
      To fix it, this makes common sample event parser, and use it to
      parse sample event correctly. (PERF_SAMPLE_READ is unsupported
      for now though, it seems to be not using.)
      Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <87hbs48imv.fsf@devron.myhome.or.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      180f95e2
  5. 01 12月, 2009 1 次提交
    • L
      perf annotate: Fix perf data parsing · bab81b62
      Li Zefan 提交于
      perf-annotate doesn't parse perf.data correctly in that it
      doesn't read perf header. Fix this by using
      mmap_dispatch_perf_file().
      
      Before:
      
      TOTAL events:      17565
            MMAP events:       3221
            LOST events:         10
            COMM events:        235
            EXIT events:          2
        THROTTLE events:          1
      UNTHROTTLE events:          2
            FORK events:         10
            READ events:          1
          SAMPLE events:      14083
      
      After:
      
      TOTAL events:      17290
            MMAP events:       3203
            LOST events:          0
            COMM events:        234
            EXIT events:          1
        THROTTLE events:          0
      UNTHROTTLE events:          0
            FORK events:          0
            READ events:          0
          SAMPLE events:      13852
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <4B14B201.9030708@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bab81b62
  6. 28 11月, 2009 2 次提交
    • 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
    • A
      perf tools: Reorganize event processing routines, lotsa dups killed · 62daacb5
      Arnaldo Carvalho de Melo 提交于
      While implementing event__preprocess_sample, that will do all of
      the symbol lookup in one convenient function, I noticed that
      util/process_event.[ch] were not being used at all, then started
      looking if there were other functions that could be shared
      and...
      
      All those functions really don't need to receive offset + head,
      the only thing they did was common to all of them, so do it at
      one place instead.
      
      Stats about number of each type of event processed now is done
      in a central place.
      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-11-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      62daacb5
  7. 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