1. 01 9月, 2015 1 次提交
  2. 29 8月, 2015 1 次提交
  3. 21 8月, 2015 1 次提交
  4. 07 8月, 2015 1 次提交
  5. 22 7月, 2015 3 次提交
  6. 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
  7. 26 6月, 2015 4 次提交
  8. 24 6月, 2015 1 次提交
  9. 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
  10. 16 5月, 2015 1 次提交
  11. 04 5月, 2015 1 次提交
  12. 29 4月, 2015 2 次提交
  13. 10 4月, 2015 1 次提交
  14. 08 4月, 2015 1 次提交
  15. 26 3月, 2015 1 次提交
  16. 23 2月, 2015 2 次提交
  17. 11 2月, 2015 1 次提交
  18. 07 2月, 2015 1 次提交
  19. 22 1月, 2015 1 次提交
  20. 21 1月, 2015 1 次提交
  21. 17 12月, 2014 7 次提交
    • A
      perf evlist: Use roundup_pow_of_two · 91529834
      Arnaldo Carvalho de Melo 提交于
      And remove the equivalent next_pow2{_l} functions.
      
      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: 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-hl9ct3wcbs5deai3v5ljmuws@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      91529834
    • A
      perf tools: Make the mmap length autotuning more robust · 1be300f4
      Arnaldo Carvalho de Melo 提交于
      If /proc/sys/kernel/perf_event_mlock_kb is not (power of 2 + PAGE_SIZE_in_kb)
      and we let the perf tools do mmap length autosizing based on that, then, for
      non-CAP_IPC_LOCK users when /proc/sys/kernel/perf_event_paranoid is > -1, then
      we get an -EINVAL that ends up in:
      
        [acme@ssdandy linux]$ trace usleep 1
        Invalid argument
        [acme@ssdandy linux]$ perf record usleep 1
        failed to mmap with 22 (Invalid argument)
      
      After this fix:
      
        [acme@ssdandy linux]$ trace usleep 1
        <SNIP>
         0.806 ( 0.006 ms): munmap(addr: 0x7f7e4740a000, len: 66467) = 0
         0.869 ( 0.002 ms): brk(                                   ) = 0x7bb000
         0.873 ( 0.003 ms): brk(brk: 0x7dc000                      ) = 0x7dc000
         0.877 ( 0.001 ms): brk(                                   ) = 0x7dc000
         0.953 ( 0.058 ms): nanosleep(rqtp: 0x7fff26ab9420         ) = 0
         0.959 ( 0.000 ms): exit_group(
        [acme@ssdandy linux]$ perf record usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.017 MB perf.data (~759 samples) ]
        [acme@ssdandy linux]$
      
      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: 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-6p6l5ou6jev6o7ymc4nn1n2a@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1be300f4
    • A
      tools: Move code originally from linux/log2.h to tools/include/linux/ · 0389cd1f
      Arnaldo Carvalho de Melo 提交于
      From tools/perf/util/include/linux, so that it becomes accessible to
      other tools/.
      
      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: 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-uqohgzilp3ebd3cbybnf3luc@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0389cd1f
    • A
      perf evlist: Do not use hard coded value for a mmap_pages default · 8185e881
      Arnaldo Carvalho de Melo 提交于
      So far what is in there by default is what we were using: 512KB + the
      control page, but the admin may change that, and if it does to a smaller
      value, all calls to tooling for non root users start failing, requiring
      that the user manually set --mmap_pages/-m.
      
      Use instead what is in /proc/sys/kernel/perf_event_mlock_kb.
      
      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: 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-2f6mtm8xu3wo5lhkql6jdblh@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8185e881
    • A
      perf evlist: Improve the strerror_mmap method · e965bea1
      Arnaldo Carvalho de Melo 提交于
      Considering the per user locked pages limit, improve the message when a
      user uses multiple simultaneous perf mmap calls:
      
      When the request is more than the current maximum:
      
        [acme@ssdandy linux]$ trace -m 128 usleep 1
        Error: Operation not permitted.
        Hint:  Check /proc/sys/kernel/perf_event_mlock_kb (516 kB) setting.
        Hint:  Tried using 516 kB.
        Hint:  Try 'sudo sh -c "echo 1032 > /proc/sys/kernel/perf_event_mlock_kb"', or
        Hint:  Try using a smaller -m/--mmap-pages value.
        [acme@ssdandy linux]$
      
      And when the limit is less than that:
      
        [acme@ssdandy linux]$ trace -m 512 usleep 1
        Error: Operation not permitted.
        Hint:  Check /proc/sys/kernel/perf_event_mlock_kb (2056 kB) setting.
        Hint:  Tried using 2052 kB.
        Hint:  Try using a smaller -m/--mmap-pages value.
        [acme@ssdandy linux]$
      
      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: 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-yqdie3c8qvdgenwleri267d4@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e965bea1
    • A
      perf evlist: Clarify sterror_mmap variable names · e5d4a290
      Arnaldo Carvalho de Melo 提交于
      Prep patch for doing further checks like when the number of pages that
      is being attempted is actually below /proc/sys/kernel/perf_event_mlock_kb but
      the operation fails because the user doesn't have CAP_IPC_LOCK.
      
      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: 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-wetzlux7mzvofu5cuji5i71i@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e5d4a290
    • A
      perf evlist: Fixup brown paper bag on "hint" for --mmap-pages cmdline arg · 0a2138b2
      Arnaldo Carvalho de Melo 提交于
      When failing due to asking for a number of mmap pages that is more than
      the max, it was suggesting that an even bigger number of mmap pages
      should be specified, doh, au contraire!
      
      Before:
      
        [acme@ssdandy linux]$ trace -m 128 usleep 1
        Error:	Operation not permitted.
        Hint:	Check /proc/sys/kernel/perf_event_mlock_kb (516 kB) setting.
        Hint:	Tried using 516 kB.
        Hint:	Try using a bigger -m/--mmap-pages value.
        [acme@ssdandy linux]$
      
      After:
      
        [acme@ssdandy linux]$ trace -m 128 usleep 1
        Error:	Operation not permitted.
        Hint:	Check /proc/sys/kernel/perf_event_mlock_kb (516 kB) setting.
        Hint:	Tried using 516 kB.
        Hint:	Try using a smaller -m/--mmap-pages value.
        [acme@ssdandy linux]$
      
      And to (really) clarify what happens above, when what the user requests
      is <= max and even then it fails, a changeset is being made to tell that
      this is a per user limit, not per process (in the above example there
      was another 'perf trace' running for this user, which was using all the
      pages it could use).
      
      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: 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-8qope8lxb898narnq5kmu2gf@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a2138b2
  22. 12 12月, 2014 1 次提交
  23. 19 11月, 2014 1 次提交
  24. 29 10月, 2014 2 次提交
    • A
      perf tools: Use evlist__for_each in a few remaining places · cba9b847
      Arnaldo Carvalho de Melo 提交于
      Where direct use of the longer form using list_for_entry() was being
      used.
      
      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: 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-v4fw80flg25nkl8jgeod3ot9@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cba9b847
    • 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