08 Aug, 2013

1 commit


31 Jan, 2012

1 commit

  • We want to be woken up for every PERF_RECORD_ event, attr.wakeup_events
    is only for PERF_RECORD_SAMPLE, so also use attr.watermark = 1 to fix
    that.

    Suggested-by: Peter Zijlstra
    Cc: David Ahern
    Cc: Frederic Weisbecker
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/n/tip-v3lnpwgrr8mllcr3ntduuqvc@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

31 Jan, 2011

1 commit

  • 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
    Cc: Ingo Molnar
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Tom Zanussi
    LKML-Reference:
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

30 Jan, 2011

1 commit

  • 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
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Tom Zanussi
    LKML-Reference:
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo