1. 26 3月, 2010 1 次提交
    • A
      perf tools: Introduce struct map_symbol · 59fd5306
      Arnaldo Carvalho de Melo 提交于
      That will be in both struct hist_entry and struct
      callchain_list, so that the TUI can store a pointer to the pair
      (map, symbol) in the trees where hist_entries and
      callchain_lists are present, to allow precise annotation instead
      of looking for the first symbol with the selected name.
      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: <1269459619-982-4-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      59fd5306
  2. 16 3月, 2010 2 次提交
    • A
      perf top: Improve the autosizing of column lenghts · b63be8d7
      Arnaldo Carvalho de Melo 提交于
      When profiling C++ workloads the symbol name length can be
      really big, so cap it before it garbles the result.
      
      This builds upon the autosizing already present where we choose
      to use the short, basename of DSOs instead of its long, full
      pathname.
      Reported-by: NPavel Krauz <krauz@cngroup.cz>
      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: <1268676230-9261-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b63be8d7
    • A
      perf annotate: Properly notify the user that vmlinux is missing · d06d92b7
      Arnaldo Carvalho de Melo 提交于
      Before this patch we would not find a vmlinux, then try to pass
      objdump "[kernel.kallsyms]" as the filename, it would get
      confused and produce no output:
      
       [root@doppio ~]# perf annotate n_tty_write
      
       ------------------------------------------------
        Percent |      Source code & Disassembly of [kernel.kallsyms]
       ------------------------------------------------
      
      Now we check that and emit meaningful warning:
      
       [root@doppio ~]# perf annotate n_tty_write
       Can't annotate n_tty_write: No vmlinux file was found in the
       path: [0] vmlinux
       [1] /boot/vmlinux
       [2] /boot/vmlinux-2.6.34-rc1-tip+
       [3] /lib/modules/2.6.34-rc1-tip+/build/vmlinux
       [4] /usr/lib/debug/lib/modules/2.6.34-rc1-tip+/vmlinux
       [root@doppio ~]#
      
      This bug was introduced when we added automatic search for
      vmlinux, before that time the user had to specify a vmlinux
      file.
      
      v2: Print the warning just for the first symbol found when no
          symbol name is specified, otherwise it will spam the screen
          repeating the warning for each symbol.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      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>
      Cc: <stable@kernel.org>
      LKML-Reference: <1268669073-6856-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d06d92b7
  3. 15 3月, 2010 1 次提交
    • A
      perf top: Properly notify the user that vmlinux is missing · b0a9ab62
      Arnaldo Carvalho de Melo 提交于
      Before this patch this message would very briefly appear on the
      screen and then the screen would get updates only on the top,
      for number of interrupts received, etc, but no annotation would
      be performed:
      
       [root@doppio linux-2.6-tip]# perf top -s n_tty_write > /tmp/bla
       objdump: '[kernel.kallsyms]': No such file
      
      Now this is what the user gets:
      
       [root@doppio linux-2.6-tip]# perf top -s n_tty_write
       Can't annotate n_tty_write: No vmlinux file was found in the
       path: [0] vmlinux
       [1] /boot/vmlinux
       [2] /boot/vmlinux-2.6.33-rc5
       [3] /lib/modules/2.6.33-rc5/build/vmlinux
       [4] /usr/lib/debug/lib/modules/2.6.33-rc5/vmlinux
       [root@doppio linux-2.6-tip]#
      
      This bug was introduced when we added automatic search for
      vmlinux, before that time the user had to specify a vmlinux
      file.
      Reported-by: NDavid S. Miller <davem@davemloft.net>
      Reported-by: NIngo Molnar <mingo@elte.hu>
      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>
      Cc: <stable@kernel.org>
      LKML-Reference: <1268664418-28328-2-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b0a9ab62
  4. 26 2月, 2010 1 次提交
  5. 04 2月, 2010 3 次提交
    • A
      perf record: Stop intercepting events, use postprocessing to get build-ids · 6122e4e4
      Arnaldo Carvalho de Melo 提交于
      We want to stream events as fast as possible to perf.data, and
      also in the future we want to have splice working, when no
      interception will be possible.
      
      Using build_id__mark_dso_hit_ops to create the list of DSOs that
      back MMAPs we also optimize disk usage in the build-id cache by
      only caching DSOs that had hits.
      Suggested-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1265223128-11786-6-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6122e4e4
    • A
      perf symbols: Ditch vdso global variable · 8d92c02a
      Arnaldo Carvalho de Melo 提交于
      We can check using strcmp, most DSOs don't start with '[' so the
      test is cheap enough and we had to test it there anyway since
      when reading perf.data files we weren't calling the routine that
      created this global variable and thus weren't setting it as
      "loaded", which was causing a bogus:
      
        Failed to open [vdso], continuing without symbols
      
      Message as the first line of 'perf report'.
      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: <1265223128-11786-3-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d92c02a
    • A
      perf symbols: Remove perf_session usage in symbols layer · 9de89fe7
      Arnaldo Carvalho de Melo 提交于
      I noticed while writing the first test in 'perf regtest' that to
      just test the symbol handling routines one needs to create a
      perf session, that is a layer centered on a perf.data file,
      events, etc, so I untied these layers.
      
      This reduces the complexity for the users as the number of
      parameters to most of the symbols and session APIs now was
      reduced while not adding more state to all the map instances by
      only having data that is needed to split the kernel (kallsyms
      and ELF symtab sections) maps and do vmlinux relocation on the
      main kernel map.
      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: <1265223128-11786-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9de89fe7
  6. 29 1月, 2010 2 次提交
  7. 21 1月, 2010 1 次提交
    • A
      perf buildid-cache: Add new command to manage build-id cache · ef12a141
      Arnaldo Carvalho de Melo 提交于
      For now it just has operations to examine a given file, find its
      build-id and add or remove it to/from the cache.
      
      Useful, for instance, when adding binaries sent together with a
      perf.data file, so that we can add them to the cache and have
      the tools find it when resolving symbols.
      
      It'll also manage the size of the cache like 'ccache' does.
      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: <1264008525-29025-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ef12a141
  8. 16 1月, 2010 2 次提交
  9. 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
  10. 13 1月, 2010 3 次提交
  11. 28 12月, 2009 2 次提交
    • A
      perf record: Introduce a symtab cache · 4cf40131
      Arnaldo Carvalho de Melo 提交于
      Now a cache will be created in a ~/.debug debuginfo like
      hierarchy, so that at the end of a 'perf record' session all the
      binaries (with build-ids) involved get collected and indexed by
      their build-ids, so that perf report can find them.
      
      This is interesting when developing software where you want to
      do a 'perf diff' with the previous build and opens avenues for
      lots more interesting tools, like a 'perf diff --graph' that
      takes more than two binaries into account.
      
      Tunables for collecting just the symtabs can be added if one
      doesn't want to have the full binary, but having the full binary
      allows things like 'perf rerecord' or other tools that can
      re-run the tests by having access to the exact binary in some
      perf.data file, so it may well be interesting to keep the full
      binary there.
      
      Space consumption is minimised by trying to use hard links, a
      'perf cache' tool to manage the space used, a la ccache is
      required to purge older entries.
      
      With this in place it will be possible also to introduce new
      commands, 'perf archive' and 'perf restore' (or some more
      suitable and future proof names) to create a cpio/tar file with
      the perf data and the files in the cache that _had_ perf hits of
      interest.
      
      There are more aspects to polish, like finding the right vmlinux
      file to cache, etc, but this is enough for a first step.
      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: <1261957026-15580-10-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4cf40131
    • A
      perf session: Move full_paths config to symbol_conf · f7d87444
      Arnaldo Carvalho de Melo 提交于
      Now perf_event_ops has just that, event handlers.
      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: <1261957026-15580-8-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f7d87444
  12. 16 12月, 2009 4 次提交
  13. 14 12月, 2009 1 次提交
    • 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
  14. 12 12月, 2009 3 次提交
    • A
      perf symbols: Ditch dso->find_symbol · ea08d8cb
      Arnaldo Carvalho de Melo 提交于
      It is always wired to dso__find_symbol.
      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: <1260564999-13371-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ea08d8cb
    • A
      perf symbols: Allow lookups by symbol name too · 79406cd7
      Arnaldo Carvalho de Melo 提交于
      Configurable via symbol_conf.sort_by_name, so that the cost of an
      extra rb_node on all 'struct symbol' instances is not paid by tools
      that only want to decode addresses.
      
      How to use it:
      
      	symbol_conf.sort_by_name = true;
      	symbol_init(&symbol_conf);
      
      	struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
      
      	if (map == NULL) {
      		pr_err("couldn't find map!\n");
      		kernel_maps__fprintf(stdout);
      	} else {
      		struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
      		if (sym == NULL)
      			pr_err("couldn't find symbol %s!\n", sym_filter);
      		else
      			pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
      	}
      
      Looking over the vmlinux/kallsyms is common enough that I'll add a
      variable to the upcoming struct perf_session to avoid the need to
      use map_groups__find_by_name to get the main vmlinux/kallsyms map.
      
      The above example looks on the 'variable' symtab, but it is just
      like that for the functions one.
      
      Also the sort operation is done when we first use
      map__find_symbol_by_name, in a lazy way.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      79406cd7
    • 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
  15. 28 11月, 2009 7 次提交
    • 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 symbols: Support multiple symtabs in struct thread · 95011c60
      Arnaldo Carvalho de Melo 提交于
      Making the routines that were so far specific to the kernel maps
      useful for all threads.
      
      This is done by making the kernel maps be contained in a kernel
      "thread".
      
      This gets the kernel specific routines closer to the userspace
      counterparts, which will help in reducing the boilerplate for
      resolving a symbol, as will be demonstrated in the next patches.
      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: <1259346563-12568-9-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      95011c60
    • A
      perf symbols: Better support for multiple symbol tables per dso · 6a4694a4
      Arnaldo Carvalho de Melo 提交于
      By using an array of rb_roots in struct dso we can, from a
      struct map instance to get the right symbol rb_tree more easily.
      This way we can have just one symbol lookup method for struct
      map instances, map__find_symbol, instead of one per symtab type
      (functions, variables).
      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: <1259346563-12568-6-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6a4694a4
    • A
      perf symbols: Add a 'type' field to struct map · 3610583c
      Arnaldo Carvalho de Melo 提交于
      That way we will be able to check if the right symtab is loaded
      in the underlying DSO.
      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: <1259346563-12568-5-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3610583c
    • A
      perf symbols: Unexport kernel_map__functions · 605ca4ba
      Arnaldo Carvalho de Melo 提交于
      perf annotate was the only user, and it doesn't really need it.
      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: <1259346563-12568-4-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      605ca4ba
    • A
      perf symbols: Split the dsos list into kernel and user parts · b0da954a
      Arnaldo Carvalho de Melo 提交于
      We don't need to look at modules in dsos__findnew because the
      kernel events come only with user DSOs. Also we need a way to
      list just the module DSOs so that we can create multiple sets of
      maps, now that we will support maps for the variables in a
      symtab.
      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: <1259346563-12568-3-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b0da954a
    • A
      perf symbols: Rename kernel_mapto kernel_map[s]__functions · 61f37a82
      Arnaldo Carvalho de Melo 提交于
      As we'll have kernel_map[s]__variables too.
      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: <1259346563-12568-2-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      61f37a82
  16. 24 11月, 2009 3 次提交
    • A
      perf symbols: Rename find_symbol routines to find_function · fcf1203a
      Arnaldo Carvalho de Melo 提交于
      Paving the way for supporting variable in adition to function
      symbols.
      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: <1259074912-5924-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fcf1203a
    • A
      perf symbols: Simplify symbol machinery setup · b32d133a
      Arnaldo Carvalho de Melo 提交于
      And also express its configuration toggles via a struct.
      
      Now all one has to do is to call symbol__init(NULL) if the
      defaults are OK, or pass a struct symbol_conf pointer with the
      desired configuration.
      
      If a tool uses kernel_maps__find_symbol() to look at the kernel
      and modules mappings for a symbol but didn't call symbol__init()
      first, that will generate a one time warning too, alerting the
      subcommand developer that symbol__init() must be called.
      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: <1259071517-3242-2-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b32d133a
    • A
      perf symbols: Look for vmlinux in more places · cc612d81
      Arnaldo Carvalho de Melo 提交于
      Now that we can check the buildid to see if it really matches,
      this can be done safely:
      
        vmlinux
        /boot/vmlinux
        /boot/vmlinux-<uts.release>
        /lib/modules/<uts.release>/build/vmlinux
        /usr/lib/debug/lib/modules/%s/vmlinux
      
      More can be added - if you know about distros that put the
      vmlinux somewhere else please let us know.
      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: <1259001550-8194-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cc612d81
  17. 21 11月, 2009 2 次提交
    • A
      perf symbols: Do lazy symtab loading for the kernel & modules too · c338aee8
      Arnaldo Carvalho de Melo 提交于
      Just like we do with the other DSOs. This also simplifies the
      kernel_maps setup process, now all that the tools need to do is
      to call kernel_maps__init and the maps for the modules and
      kernel will be created, then, later, when
      kernel_maps__find_symbol() is used, it will also call
      maps__find_symbol that already checks if the symtab was loaded,
      loading it if needed.
      
      Now if one does 'perf top --hide_kernel_symbols' we won't pay
      the price of loading the (many) symbols in /proc/kallsyms or
      vmlinux.
      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: <1258757489-5978-4-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c338aee8
    • A
      perf symbols: Remove unrelated actions from dso__load_kernel_sym · 6671cb16
      Arnaldo Carvalho de Melo 提交于
      It should just load kernel symbols, not load the list of
      modules. There are more stuff to move to other routines, but
      lets do it in several steps.
      
      End goal is to be able to defer symbol table loading till we
      find a hit for that map address range. So that the kernel &
      modules are handled just like all the other DSOs in the system.
      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: <1258757489-5978-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6671cb16
  18. 19 11月, 2009 1 次提交
    • A
      perf symbols: Capture the running kernel buildid too · 2446042c
      Arnaldo Carvalho de Melo 提交于
      [root@doppio linux-2.6-tip]# perf record -a -f sleep 3s ; perf
      buildid-list | grep vmlinux
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.171 MB perf.data (~7489
      samples) ] 18e7cc53db62a7d35e9d6f6c9ddc23017d38ee9a vmlinux
      [root@doppio linux-2.6-tip]#
      
      Several refactorings were needed so that we can have symmetry
      between dsos__load_modules() and dsos__load_kernel(), i.e. those
      functions will respectively create and add to the dsos list the
      loaded modules and kernel, with its buildids, but not load its
      symbols. That is something the subcomands that need will have to
      call dso__load_kernel_sym(), just like we do with modules with
      dsos__load_module_sym()/dso__load_module_sym().
      
      Next csets will actually use this info to stop producing bogus
      results using mismatched vmlinux and .ko files.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Roland McGrath <roland@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: <1258582853-8579-4-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2446042c