1. 30 1月, 2015 1 次提交
  2. 29 10月, 2014 2 次提交
    • A
      perf session: Add perf_session__deliver_synth_event() · a293829d
      Adrian Hunter 提交于
      Add a function to deliver synthesized events from within a session.
      
      Intel PT decoding works by synthesizing events (primarily branch events)
      that can then be consumed by existing tools.  This function will be used
      to deliver those events.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      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/r/1414417770-18602-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a293829d
    • A
      perf tools: Add id index · 3c659eed
      Adrian Hunter 提交于
      Add an index of the event identifiers, in preparation for Intel PT.
      
      The event id (also called the sample id) is a unique number
      allocated by the kernel to the event created by perf_event_open().  Events
      can include the event id by having a sample type including PERF_SAMPLE_ID or
      PERF_SAMPLE_IDENTIFIER.
      
      Currently the main use of the event id is to match an event back to the
      evsel to which it belongs i.e. perf_evlist__id2evsel()
      
      The purpose of this patch is to make it possible to match an event back to
      the mmap from which it was read.  The reason that is useful is because the
      mmap represents a time-ordered context (either for a cpu or for a thread).
      Intel PT decodes trace information on that basis.  In full-trace mode, that
      information can be recorded when the Intel PT trace is read, but in
      sample-mode the Intel PT trace data is embedded in a sample and it is in
      that case that the "id index" is needed.
      
      So the mmaps are numbered (idx) and the cpu and tid recorded against the id
      by perf_evlist__set_sid_idx() which is called by perf_evlist__mmap_per_evsel().
      
      That information is recorded on the perf.data file in the new "id index".
      idx, cpu and tid are added to struct perf_sample_id (which is the node of
      evlist's hash table to match ids to evsels).  The information can be
      retrieved using perf_evlist__id2sid().  Note however this all depends on
      having a sample type including PERF_SAMPLE_ID or PERF_SAMPLE_IDENTIFIER,
      otherwise ids are not recorded.
      
      The "id index" is a synthesized event record which will be created when
      Intel PT sampling is used by calling perf_event__synthesize_id_index().
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      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/r/1414417770-18602-2-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3c659eed
  3. 14 10月, 2014 1 次提交
    • A
      perf session: Remove last reference to hists struct · 2a1731fb
      Arnaldo Carvalho de Melo 提交于
      Now perf_session doesn't require that the evsels in its evlist are hists
      containing ones.
      
      Tools that are hists based and want to do per evsel events_stats
      updates, if at some point this turns into a necessity, should do it in
      the tool specific code, keeping the session class hists agnostic.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jean Pihet <jean.pihet@linaro.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      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-cli1bgwpo82mdikuhy3djsuy@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2a1731fb
  4. 26 9月, 2014 1 次提交
  5. 14 8月, 2014 1 次提交
  6. 12 8月, 2014 6 次提交
  7. 17 7月, 2014 1 次提交
  8. 20 12月, 2013 1 次提交
    • A
      perf symbols: Add 'machine' member to struct addr_location · cc22e575
      Arnaldo Carvalho de Melo 提交于
      The addr_location struct should fully qualify an address, and to do that
      it should have in it the machine where the thread was found.
      
      Thus all functions that receive an addr_location now don't need to also
      receive a 'machine', those functions just need to access al->machine
      instead, just like it does with the other parts of an address location:
      al->thread, al->map, etc.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      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@kernel.org>
      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-o51iiee7vyq4r3k362uvuylg@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cc22e575
  9. 13 12月, 2013 1 次提交
  10. 10 12月, 2013 1 次提交
    • A
      perf script: Add an option to print the source line number · cc8fae1d
      Adrian Hunter 提交于
      Add field 'srcline' that displays the source file name and line number
      associated with the sample ip.  The information displayed is the same as
      from addr2line.
      
       $ perf script -f comm,tid,pid,time,ip,sym,dso,symoff,srcline
                  grep 10701/10701 2497321.421013:  ffffffff81043ffa native_write_msr_safe+0xa ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/arch/x86/include/asm/msr.h:95
                  grep 10701/10701 2497321.421984:  ffffffff8165b6b3 _raw_spin_lock+0x13 ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/arch/x86/include/asm/spinlock.h:54
                  grep 10701/10701 2497321.421990:  ffffffff810b64b3 tick_sched_timer+0x53 ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/kernel/time/tick-sched.c:840
                  grep 10701/10701 2497321.421992:  ffffffff8106f63f run_timer_softirq+0x2f ([kernel.kallsyms])
        /usr/src/debug/kernel-3.9.fc17/linux-3.9.10-100.fc17.x86_64/kernel/timer.c:1372
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.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 <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1386315778-11633-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cc8fae1d
  11. 05 12月, 2013 2 次提交
  12. 06 11月, 2013 1 次提交
  13. 22 10月, 2013 3 次提交
  14. 19 9月, 2013 1 次提交
  15. 12 8月, 2013 3 次提交
  16. 08 8月, 2013 2 次提交
  17. 13 7月, 2013 1 次提交
  18. 29 5月, 2013 1 次提交
  19. 16 3月, 2013 1 次提交
  20. 25 1月, 2013 4 次提交
  21. 09 12月, 2012 2 次提交
    • A
      perf symbols: Generalize filter in __fprintf_buildid methods · 417c2ff6
      Arnaldo Carvalho de Melo 提交于
      We had that 'with_hits' filter to show just the build ids for DSOs that
      had samples, make that generic so that we can use it in the upcoming
      buildid-cache --missing feature, to show just the build ids that are not
      in the cache.
      
      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-9nfesdfpnx7zp96yn3tmfbx0@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      417c2ff6
    • D
      perf tools: Fix mmap limitations on 32-bit · 35d48ddf
      David Miller 提交于
      This is a suggested patch to fix the bug I reported at:
      
      	http://marc.info/?l=linux-kernel&m=135033028924652&w=2
      
      Essentially, there is a hard requirement that when perf analyzes a
      trace, it must have the entire thing mmap()'d.
      
      Therefore the scheme used on 32-bit where we have a fixed (8) number of
      32MB mmaps, and cycle through them, simply does not work.
      
      One of the reasons this requirement exists is because the iterators
      maintain references to perf entry objects and those references don't
      just simply go away when this mmap code decides to cycle an old mmap
      area out and reuse it.  At this point, those entry pointers now point to
      garbage resulting in unpredictable behavior and crashes.
      
      It is better to try to mmap() as much as we can and if we do actually
      run into address space limitations, the failure of the mmap() call will
      indicate that and stop processing.
      
      I noticed that perf_session->mmap_window is set to a constant in one
      location, and only used in one other location.  So I got rid of it
      altogether.
      
      So we adjust the size of the mmaps[] array to the maximum we could need.
      On 64-bit we only need one slot.  On 32-bit we could need up to 128 (128
      * 32MB == 4GB).
      
      I've verified that this allows a large (~600MB) perf.data file to be
      analyzed properly with a 32-bit perf binary, which previously was not
      possible.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20121110.141219.582924082787523608.davem@davemloft.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      35d48ddf
  22. 20 11月, 2012 1 次提交
    • D
      perf: Make perf build for x86 with UAPI disintegration applied · d2709c7c
      David Howells 提交于
      Make perf build for x86 once the UAPI disintegration patches for that arch
      have been applied by adding the appropriate -I flags - in the right order -
      and then converting some #includes that use ../.. notation to find main kernel
      headerfiles to use <asm/foo.h> and <linux/foo.h> instead.
      
      Note that -Iarch/foo/include/uapi is present _before_ -Iarch/foo/include.
      This makes sure we get the userspace version of the pt_regs struct.  Ideally,
      we wouldn't have the latter -I flag at all, but unfortunately we want
      asm/svm.h and asm/vmx.h in builtin-kvm.c and these aren't part of the UAPI -
      at least not for x86.  I wonder if the bits outside of the __KERNEL__ guards
      *should* be transferred there.
      
      I note also that perf seems to do its dependency handling manually by listing
      all the header files it might want to use in LIB_H in the Makefile.  Can this
      be changed to use -MD?
      
      Note that to do make this work, we need to export and UAPI disintegrate
      linux/hw_breakpoint.h, which I think should've been exported previously so that
      perf can access the bits.  We have to do this in the same patch to maintain
      bisectability.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d2709c7c
  23. 09 11月, 2012 1 次提交
  24. 15 10月, 2012 1 次提交