1. 01 10月, 2015 1 次提交
    • A
      perf tools: By default use the most precise "cycles" hw counter available · 7f8d1ade
      Arnaldo Carvalho de Melo 提交于
      If the user doesn't specify any event, try the most precise "cycles"
      available, i.e. start by "cycles:ppp" and go on removing "p" till it
      works.
      
      E.g.
      
        $ perf record usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.017 MB perf.data (11 samples) ]
        $ perf evlist
        cycles:pp
        $ perf evlist -v
        cycles:pp: size: 112, { sample_period, sample_freq }: 4000, sample_type:
        IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1,
        enable_on_exec: 1, task: 1, precise_ip: 2, sample_id_all: 1,
        exclude_guest: 1, mmap2: 1, comm_exec: 1
        $ grep 'model name' /proc/cpuinfo | head -1
        model name	: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
        $
      
      When 'cycles' appears explicitely is specified this will not be tried,
      i.e. the user has full control of the level of precision to be used:
      
        $ perf record -e cycles usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.016 MB perf.data (9 samples) ]
        $ perf evlist
        cycles
        $ perf evlist -v
        cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type:
        IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1,
        enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1, mmap2:
        1, comm_exec: 1
        $
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Chandler Carruth <chandlerc@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://www.youtube.com/watch?v=nXaxk27zwlk
      Link: http://lkml.kernel.org/n/tip-b1ywebmt22pi78vjxau01wth@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7f8d1ade
  2. 29 9月, 2015 2 次提交
  3. 15 9月, 2015 13 次提交
  4. 01 9月, 2015 1 次提交
  5. 29 8月, 2015 1 次提交
  6. 21 8月, 2015 1 次提交
  7. 07 8月, 2015 1 次提交
  8. 22 7月, 2015 3 次提交
  9. 06 7月, 2015 2 次提交
    • A
      perf evlist: Make perf_evlist__set_filter use perf_evsel__set_filter · 94ad89bc
      Arnaldo Carvalho de Melo 提交于
      Instead of calling perf_evsel__apply_filter straight away, so that
      we can, in the next patches, expand the filter with more conditions
      before actually calling the ioctl to pass the end result filter to
      the kernel.
      
      Now we need to call perf_evlist__apply_filters() after the filter
      is completely setup, i.e. do the ioctl calls.
      
      The perf_evlist__apply_filters() method was already in place, because
      that is the model for the other tools that receives filters in the
      command line: go on setting then in the evsel->filter and only at
      the end, after parsing the whole command line, apply them.
      
      We get, as a bonus, a more expressive message that states which
      event, if any, failed to have the filter applied to, with an
      error message stating what happened.
      
      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: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-f429pgz75ryz7tpe6v74etre@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      94ad89bc
    • A
      perf evsel: Rename set_filter to apply_filter · f47805a2
      Arnaldo Carvalho de Melo 提交于
      We need to be able to go on constructing a complex filter in multiple
      stages, since we can only set one filter per event.
      
      For instance, we need to be able, in 'perf trace' to filter by the
      'common_pid' field all the time, if only for the tracer itself, to
      avoid a feedback loop, and, in addition, we may want to filter the
      raw_syscalls:sys_{enter,exit} events by its 'id' filter, when using
      'perf trace -e open,close' or 'perf trace -e !open,close', i.e. when
      we are interested in just a subset of syscalls or when we are not
      interested in it.
      
      So we will have:
      
         perf_evsel__set_filter(evsel, char *filter)
      
             Replaces whatever is in evsel->filter.
      
         perf_evsel__append_filter(evsel, const char *op, char *filter)
      
             Appends, using op ("&&" or "||") with what is in evsel->filter.
      
         perf_evsel__apply_filter(evsel, filter):
      
              That actually applies a filter, be it the one being
              constructed in evsel->filter, or any other, for tools
              with more specific ways to build the filter, issuing
              the appropriate ioctl for all the evsel fds.
      
      The same changes will be made to the evlist__{set,apply} variants to
      keep everything consistent.
      
      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: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-2s5z9xtpnc2lwio3cv5x0jek@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f47805a2
  10. 26 6月, 2015 4 次提交
  11. 24 6月, 2015 1 次提交
  12. 18 6月, 2015 2 次提交
    • A
      perf evlist: Add toggle_enable() method · 2b56bcfb
      Arnaldo Carvalho de Melo 提交于
      For an upcoming feature in 'perf top' we will have a hotkey to
      enable/disable events, so remember if the events in the list are
      enabled or disabled and allows toggling this state using a new
      method.
      
      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: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-64c4jvdl5feg2zhimxvokqka@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2b56bcfb
    • S
      perf trace: Fix race condition at the end of started workloads · 7951722d
      Sukadev Bhattiprolu 提交于
      I get following crash on multiple systems and across several releases
      (at least since v3.18).
      
      	Core was generated by `/tmp/perf trace sleep 0.2 '.
      	Program terminated with signal SIGSEGV, Segmentation fault.
      	#0  perf_mmap__read_head (mm=0x3fff9bf30070) at util/evlist.h:195
      	195		u64 head = ACCESS_ONCE(pc->data_head);
      	(gdb) bt
      	#0  perf_mmap__read_head (mm=0x3fff9bf30070) at util/evlist.h:195
      	#1  perf_evlist__mmap_read (evlist=0x10027f11910, idx=<optimized out>)
      	    at util/evlist.c:637
      	#2  0x000000001003ce4c in trace__run (argv=<optimized out>,
      	    argc=<optimized out>, trace=0x3fffd7b28288) at builtin-trace.c:2259
      	#3  cmd_trace (argc=<optimized out>, argv=<optimized out>,
      	    prefix=<optimized out>) at builtin-trace.c:2799
      	#4  0x00000000100657b8 in run_builtin (p=0x10176798 <commands+480>, argc=3,
      	    argv=0x3fffd7b2b550) at perf.c:370
      	#5  0x00000000100063e8 in handle_internal_command (argv=0x3fffd7b2b550, argc=3)
      	    at perf.c:429
      	#6  run_argv (argv=0x3fffd7b2af70, argcp=0x3fffd7b2af7c) at perf.c:473
      	#7  main (argc=3, argv=0x3fffd7b2b550) at perf.c:588
      
      The problem seems to be a race condition, when the application has just
      exited.  Some/all fds associated with the perf-events (tracepoints) go
      into a POLLHUP/ POLLERR state and the mmap region associated with those
      events are unmapped (in perf_evlist__filter_pollfd()).
      
      But we go back and do a perf_evlist__mmap_read() which assumes that the
      mmaps are still valid and we hit the crash.
      
      If the mapping for an event is released, its refcnt is 0 (and ->base
      is NULL), so ensure we have non-zero refcount before accessing the map.
      
      Note that perf-record has a similar logic but unlike perf-trace, the
      record__mmap_read_all() checks the evlist->mmap[i].base before accessing
      the map.
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Li Zhang <zhlcindy@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20150612060003.GA19913@us.ibm.com
      [ Fixed it up to use atomic_read() ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7951722d
  13. 16 5月, 2015 1 次提交
  14. 04 5月, 2015 1 次提交
  15. 29 4月, 2015 2 次提交
  16. 10 4月, 2015 1 次提交
  17. 08 4月, 2015 1 次提交
  18. 26 3月, 2015 1 次提交
  19. 23 2月, 2015 1 次提交