1. 31 1月, 2011 1 次提交
    • A
      perf evlist: Store pointer to the cpu and thread maps · 7e2ed097
      Arnaldo Carvalho de Melo 提交于
      So that we don't have to pass it around to the several methods that
      needs it, simplifying usage.
      
      There is one case where we don't have the thread/cpu map in advance,
      which is in the parsing routines used by top, stat, record, that we have
      to wait till all options are parsed to know if a cpu or thread list was
      passed to then create those maps.
      
      For that case consolidate the cpu and thread map creation via
      perf_evlist__create_maps() out of the code in top and record, while also
      providing a perf_evlist__set_maps() for cases where multiple evlists
      share maps or for when maps that represent CPU sockets, for instance,
      get crafted out of topology information or subsets of threads in a
      particular application are to be monitored, providing more granularity
      in specifying which cpus and threads to monitor.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7e2ed097
  2. 30 1月, 2011 1 次提交
    • A
      perf tools: Initial python binding · 877108e4
      Arnaldo Carvalho de Melo 提交于
      First clarifying that this kind of binding is not a replacement or an
      equivalent to the 'perf script' way of using python with perf.
      
      The 'perf script' way is to process events and look at a given script
      for some python function that matches the events to pass each event for
      processing.
      
      This is a python module, i.e. everything is driven from the python
      script, that merely uses "import perf" or "from perf import".
      
      perf script is focused on tracepoints, this binding is focused on profiling as
      an initial target. More work is needed to make available tracepoint specific
      variables as event variables accessible via this binding.
      
      There is one example of such usage model, in
      tools/perf/python/twatch.py, a tool to watch "cycles" events together
      with task (fork, exit) and comm perf events.
      
      For now, due to me not being able to grok how python distutils cope with
      building C extensions outside the sources dir the install target just
      builds it, I'm using it as:
      
      [root@emilia linux]# export PYTHONPATH=~acme/git/build/perf/lib.linux-x86_64-2.6/
      [root@emilia linux]# tools/perf/python/twatch.py
      cpu:  4, pid: 30126, tid: 30126 { type: mmap, pid: 30126, tid: 30126, start: 0x4, length: 0x82e9ca03, offset: 0, filename:  }
      cpu:  6, pid:   47, tid:   47 { type: mmap, pid: 47, tid: 47, start: 0x6, length: 0xbef87c36, offset: 0, filename:  }
      cpu:  1, pid:    0, tid:    0 { type: mmap, pid: 0, tid: 0, start: 0x1, length: 0x775d1904, offset: 0, filename:  }
      cpu:  7, pid:    0, tid:    0 { type: mmap, pid: 0, tid: 0, start: 0x7, length: 0xc750aeb6, offset: 0, filename:  }
      cpu:  5, pid: 2255, tid: 2255 { type: mmap, pid: 2255, tid: 2255, start: 0x5, length: 0x76669635, offset: 0, filename:  }
      cpu:  0, pid:    0, tid:    0 { type: mmap, pid: 0, tid: 0, start: 0, length: 0x6422ef6b, offset: 0, filename:  }
      cpu:  2, pid: 2255, tid: 2255 { type: mmap, pid: 2255, tid: 2255, start: 0x2, length: 0xe078757a, offset: 0, filename:  }
      cpu:  1, pid: 5769, tid: 5769 { type: fork, pid: 30127, ppid: 5769, tid: 30127, ptid: 5769, time: 103893991270534}
      cpu:  6, pid: 30127, tid: 30127 { type: comm, pid: 30127, tid: 30127, comm: ls }
      cpu:  6, pid: 30127, tid: 30127 { type: exit, pid: 30127, ppid: 30127, tid: 30127, ptid: 30127, time: 103893993273024}
      
      The first 8 mmap events in this 8 way machine are a mistery that is still being
      investigated.
      
      More of the tools/perf/util/ APIs will be exposed via this python binding as
      the need arises. For now the focus is on creating events and processing them,
      symbol resolution is an obvious next step, with tracepoint variables as a close
      second step.
      
      Cc: Clark Williams <williams@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      877108e4