1. 11 11月, 2009 2 次提交
    • F
      perf tools: Bring linear set of section headers for features · 9e827dd0
      Frederic Weisbecker 提交于
      Build a set of section headers for features right after the
      datas. Each implemented feature will have one of such section
      header that provides the offset and the size of the data
      manipulated by the feature.
      
      The trace informations have moved after the data and are
      recorded on exit time.
      
      The new layout is as follows:
      
       -----------------------
                                   ___
       [ magic               ]      |
       [ header size         ]      |
       [ attr size           ]      |
       [ attr content offset ]      |
       [ attr content size   ]      |
       [ data offset         ]  File Headers
       [ data size           ]      |
       [ event_types offset  ]      |
       [ event_types size    ]      |
       [ feature bitmap      ]      v
      
       [ attr section        ]
       [ events section      ]
      
                                   ___
       [         X           ]      |
       [         X           ]      |
       [         X           ]    Datas
       [         X           ]      |
       [         X           ]      v
      
                                   ___
       [ Feature 1 offset    ]      |
       [ Feature 1 size      ] Features headers
       [ Feature 2 offset    ]      |
       [ Feature 2 size      ]      v
      
       [ Feature 1 content   ]
       [ Feature 2 content   ]
       -----------------------
      
      We have as many feature's section headers as we have features in
      use for the current file.
      
      Say Feat 1 and Feat 3 are used by the file, but not Feat 2. Then
      the feature headers will be like follows:
      
      [ Feature 1 offset    ]      |
      [ Feature 1 size      ] Features headers
      [ Feature 3 offset    ]      |
      [ Feature 3 size      ]      v
      
      There is no hole to cover Feature 2 that is not in use here. We
      only need to cover the needed headers in order, from the lowest
      feature bit to the highest.
      
      Currently we have two features: HEADER_TRACE_INFO and
      HEADER_BUILD_ID. Both have their contents that follow the
      feature headers. Putting the contents right after the feature
      headers is not mandatory though. While we keep the feature
      headers right after the data and in order, their offsets can
      point everywhere. We have just put the two above feature
      contents in the end of the file for convenience.
      
      The purpose of this layout change is to have a file format that
      scales while keeping it simple: having such linear feature
      headers is less error prone wrt forward/backward compatibility
      as the content of a feature can be put anywhere, its location
      can even change by the time, it's fine because its headers will
      tell where it is. And we know how to find these headers,
      following the above rules.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-6-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9e827dd0
    • F
      perf tools: Read the build-ids from the header layer · 4778d2e4
      Frederic Weisbecker 提交于
      Keep the build-ids reading implementation in the data mapping
      but move its call to the headers so that we have a better
      control on it (offset seeking, size passing, etc..).
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      LKML-Reference: <1257911467-28276-4-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4778d2e4
  2. 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
  3. 02 11月, 2009 1 次提交
  4. 21 10月, 2009 1 次提交
  5. 08 10月, 2009 1 次提交
    • F
      perf tools: Unify perf.data mapping and events handling · 016e92fb
      Frederic Weisbecker 提交于
      This librarizes the perf.data file mapping and handling in various
      perf tools, roughly reducing the amount of code and fixing the
      places that mmap from beginning of the file whereas we want to mmap
      from the beginning of the data, leading to page fault because the
      mmap window is too small since the trace info are written in the
      file too.
      
      TODO:
      
       - convert perf timechart too
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <20091007104729.GD5043@nowhere>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      016e92fb