1. 06 Dec, 2015 1 commit
    • Andi Kleen's avatar
      x86, tracing, perf: Add trace point for MSR accesses · 7f47d8cc
      Andi Kleen authored
      For debugging low level code interacting with the CPU it is often
      useful to trace the MSR read/writes. This gives a concise summary of
      PMU and other operations.
      perf has an ad-hoc way to do this using trace_printk, but it's
      somewhat limited (and also now spews ugly boot messages when enabled)
      Instead define real trace points for all MSR accesses.
      This adds three new trace points: read_msr and write_msr and rdpmc.
      They also report if the access faulted (if *_safe is used)
      This allows filtering and triggering on specific MSR values, which
      allows various more advanced debugging techniques.
      All the values are well defined in the CPU documentation.
      The trace can be post processed with
      Documentation/trace/postprocess/decode_msr.py to add symbolic MSR
      names to the trace.
      I only added it to native MSR accesses in C, not paravirtualized or in
      entry*.S (which is not too interesting)
      Originally the patch kit moved the MSRs out of line.  This uses an
      alternative approach recommended by Steven Rostedt of only moving the
      trace calls out of line, but open coding the access to the jump label.
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/1449018060-1742-3-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  2. 03 Nov, 2015 1 commit
  3. 21 Oct, 2015 1 commit
  4. 04 Oct, 2015 2 commits
    • Alexander Shishkin's avatar
      intel_th: Add driver infrastructure for Intel(R) Trace Hub devices · 39f40346
      Alexander Shishkin authored
      Intel(R) Trace Hub (TH) is a set of hardware blocks (subdevices) that
      produce, switch and output trace data from multiple hardware and
      software sources over several types of trace output ports encoded
      in System Trace Protocol (MIPI STPv2) and is intended to perform
      full system debugging.
      For these subdevices, we create a bus, where they can be discovered
      and configured by userspace software.
      This patch creates this bus infrastructure, three types of devices
      (source, output, switch), resource allocation, some callback mechanisms
      to facilitate communication between the subdevices' drivers and some
      common sysfs attributes.
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alexander Shishkin's avatar
      stm class: Introduce an abstraction for System Trace Module devices · 7bd1d409
      Alexander Shishkin authored
      A System Trace Module (STM) is a device exporting data in System Trace
      Protocol (STP) format as defined by MIPI STP standards. Examples of such
      devices are Intel(R) Trace Hub and Coresight STM.
      This abstraction provides a unified interface for software trace sources
      to send their data over an STM device to a debug host. In order to do
      that, such a trace source needs to be assigned a pair of master/channel
      identifiers that all the data from this source will be tagged with. The
      STP decoder on the debug host side will use these master/channel tags to
      distinguish different trace streams from one another inside one STP
      This abstraction provides a configfs-based policy management mechanism
      for dynamic allocation of these master/channel pairs based on trace
      source-supplied string identifier. It has the flexibility of being
      defined at runtime and at the same time (provided that the policy
      definition is aligned with the decoding end) consistency.
      For userspace trace sources, this abstraction provides write()-based and
      mmap()-based (if the underlying stm device allows this) output mechanism.
      For kernel-side trace sources, we provide "stm_source" device class that
      can be connected to an stm device at run time.
      Cc: linux-api@vger.kernel.org
      Reviewed-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 06 Aug, 2015 1 commit
  6. 05 Aug, 2015 1 commit
  7. 21 Jul, 2015 1 commit
  8. 13 May, 2015 1 commit
  9. 03 Apr, 2015 1 commit
  10. 09 Feb, 2015 1 commit
  11. 04 Feb, 2015 1 commit
  12. 03 Dec, 2014 1 commit
    • Byungchul Park's avatar
      tracing: Add additional marks to signal very large time deltas · 8e1e1df2
      Byungchul Park authored
      Currently, function graph tracer prints "!" or "+" just before
      function execution time to signal a function overhead, depending
      on the time. And some tracers tracing latency also print "!" or
      "+" just after time to signal overhead, depending on the interval
      between events. Even it is usually enough to do that, we sometimes
      need to signal for bigger execution time than 100 micro seconds.
      For example, I used function graph tracer to detect if there is
      any case that exit_mm() takes too much time. I did following steps
      in /sys/kernel/debug/tracing. It was easier to detect very large
      excution time with patched kernel than with original kernel.
      $ echo exit_mm > set_graph_function
      $ echo function_graph > current_tracer
      $ echo > trace
      $ cat trace_pipe > $LOGFILE
       ... (do something and terminate logging)
      $ grep "\\$" $LOGFILE
       3) $ 22082032 us |                      } /* kernel_map_pages */
       3) $ 22082040 us |                    } /* free_pages_prepare */
       3) $ 22082113 us |                  } /* free_hot_cold_page */
       3) $ 22083455 us |                } /* free_hot_cold_page_list */
       3) $ 22083895 us |              } /* release_pages */
       3) $ 22177873 us |            } /* free_pages_and_swap_cache */
       3) $ 22178929 us |          } /* unmap_single_vma */
       3) $ 22198885 us |        } /* unmap_vmas */
       3) $ 22206949 us |      } /* exit_mmap */
       3) $ 22207659 us |    } /* mmput */
       3) $ 22207793 us |  } /* exit_mm */
      And then, it was easy to find out that a schedule-out occured by
      sub_preempt_count() within kernel_map_pages().
      To detect very large function exection time caused by either problematic
      function implementation or scheduling issues, this patch can be useful.
      Link: http://lkml.kernel.org/r/1416789259-24038-1-git-send-email-byungchul.park@lge.comSigned-off-by: default avatarByungchul Park <byungchul.park@lge.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
  13. 21 Nov, 2014 1 commit
    • Masami Hiramatsu's avatar
      ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict · f8b8be8a
      Masami Hiramatsu authored
      Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
      ftrace users who may modify regs->ip to change the execution
      path. If two or more users modify the regs->ip on the same
      function entry, one of them will be broken. So they must add
      IPMODIFY flag and make sure that ftrace_set_filter_ip() succeeds.
      Note that ftrace doesn't allow ftrace_ops which has IPMODIFY
      flag to have notrace hash, and the ftrace_ops must have a
      filter hash (so that the ftrace_ops can hook only specific
      entries), because it strongly depends on the address and
      must be allowed for only few selected functions.
      Link: http://lkml.kernel.org/r/20141121102516.11844.27829.stgit@localhost.localdomain
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Seth Jennings <sjenning@redhat.com>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Vojtech Pavlik <vojtech@suse.cz>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      [ fixed up some of the comments ]
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
  14. 07 Nov, 2014 1 commit
  15. 07 Aug, 2014 1 commit
    • Chen Yucong's avatar
      mm: trace-vmscan-postprocess.pl: report the number of file/anon pages respectively · 2c51856c
      Chen Yucong authored
      Until now, the reporting from trace-vmscan-postprocess.pl is not very
      useful because we cannot directly use this script for checking the
      file/anon ratio of scanning.  This patch aims to report respectively the
      number of file/anon pages which were scanned/reclaimed by kswapd or
      direct-reclaim.  Sample output is usually something like the following.
      Direct reclaims:                          8823
      Direct reclaim pages scanned:             2438797
      Direct reclaim file pages scanned:        1315200
      Direct reclaim anon pages scanned:        1123597
      Direct reclaim pages reclaimed:           446139
      Direct reclaim file pages reclaimed:      378668
      Direct reclaim anon pages reclaimed:      67471
      Direct reclaim write file sync I/O:       0
      Direct reclaim write anon sync I/O:       0
      Direct reclaim write file async I/O:      0
      Direct reclaim write anon async I/O:      4240
      Wake kswapd requests:                     122310
      Time stalled direct reclaim:              13.78 seconds
      Kswapd wakeups:                           25817
      Kswapd pages scanned:                     170779115
      Kswapd file pages scanned:                162725123
      Kswapd anon pages scanned:                8053992
      Kswapd pages reclaimed:                   129065738
      Kswapd file pages reclaimed:              128500930
      Kswapd anon pages reclaimed:              564808
      Kswapd reclaim write file sync I/O:       0
      Kswapd reclaim write anon sync I/O:       0
      Kswapd reclaim write file async I/O:      36
      Kswapd reclaim write anon async I/O:      730730
      Time kswapd awake:                        1015.50 seconds
      Signed-off-by: default avatarChen Yucong <slaoub@gmail.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  16. 18 Jul, 2014 1 commit
  17. 16 Jul, 2014 1 commit
    • Kirill Tkhai's avatar
      sched: Transform resched_task() into resched_curr() · 8875125e
      Kirill Tkhai authored
      We always use resched_task() with rq->curr argument.
      It's not possible to reschedule any task but rq's current.
      The patch introduces resched_curr(struct rq *) to
      replace all of the repeating patterns. The main aim
      is cleanup, but there is a little size profit too:
      	$ size kernel/sched/built-in.o
      	   text	   data	    bss	    dec	    hex	filename
      	155274	  16445	   7042	 178761	  2ba49	kernel/sched/built-in.o
      	$ size vmlinux
      	   text	   data	    bss	    dec	    hex	filename
      	7411490	1178376	 991232	9581098	 92322a	vmlinux
      	$ size kernel/sched/built-in.o
      	   text	   data	    bss	    dec	    hex	filename
      	155130	  16445	   7042	 178617	  2b9b9	kernel/sched/built-in.o
      	$ size vmlinux
      	   text	   data	    bss	    dec	    hex	filename
      	7411362	1178376	 991232	9580970	 9231aa	vmlinux
      	I was choosing between resched_curr() and resched_rq(),
      	and the first name looks better for me.
      A little lie in Documentation/trace/ftrace.txt. I have not
      actually collected the tracing again. With a hope the patch
      won't make execution times much worse :)
      Signed-off-by: default avatarKirill Tkhai <tkhai@yandex.ru>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/20140628200219.1778.18735.stgit@localhostSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  18. 03 Jul, 2014 1 commit
  19. 21 May, 2014 1 commit
  20. 07 May, 2014 1 commit
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Add trace_<tracepoint>_enabled() function · 7c65bbc7
      Steven Rostedt (Red Hat) authored
      There are some code paths in the kernel that need to do some preparations
      before it calls a tracepoint. As that code is worthless overhead when
      the tracepoint is not enabled, it would be prudent to have that code
      only run when the tracepoint is active. To accomplish this, all tracepoints
      now get a static inline function called "trace_<tracepoint-name>_enabled()"
      which returns true when the tracepoint is enabled and false otherwise.
      As an added bonus, that function uses the static_key of the tracepoint
      such that no branch is needed.
        if (trace_mytracepoint_enabled()) {
      	arg = process_tp_arg();
      Will keep the "process_tp_arg()" (which may be expensive to run) from
      being executed when the tracepoint isn't enabled.
      It's best to encapsulate the tracepoint itself in the if statement
      just to keep races. For example, if you had:
        if (trace_mytracepoint_enabled())
      	arg = process_tp_arg();
      There's a chance that the tracepoint could be enabled just after the
      if statement, and arg will be undefined when calling the tracepoint.
      Link: http://lkml.kernel.org/r/20140506094407.507b6435@gandalf.local.homeAcked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
  21. 05 May, 2014 1 commit
  22. 21 Mar, 2014 1 commit
  23. 07 Mar, 2014 2 commits
  24. 10 Feb, 2014 1 commit
  25. 24 Jan, 2014 1 commit
  26. 03 Jan, 2014 2 commits
  27. 02 Jan, 2014 1 commit
  28. 22 Dec, 2013 1 commit
  29. 02 Dec, 2013 1 commit
  30. 13 Nov, 2013 1 commit
  31. 11 Nov, 2013 1 commit
  32. 27 Aug, 2013 1 commit
  33. 20 Aug, 2013 1 commit
  34. 24 Jun, 2013 1 commit
  35. 23 Jun, 2013 1 commit
  36. 20 Jun, 2013 2 commits
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Update documentation on tracepoint glob matching · c3e13c7c
      Steven Rostedt (Red Hat) authored
      b0f1a59a "tracing/filters: Use a different op for glob match" added
      glob matching to tracepoint filter strings. It uses the ftrace function
      tracing glob matching facility that allows for the wild card character (*)
      to be used at the start and/or end of the matching string.
      But the documentation still states that the filtering only allows for
      exact string matches.
      Cc: Li Zefan <lizefan@huawei.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
    • Steven Rostedt's avatar
      tracing: Add binary '&' filter for events · 1a891cf1
      Steven Rostedt authored
      There are some cases when filtering on a set flag of a field of a tracepoint
      is useful. But currently the only filtering commands for numbered fields
      is ==, !=, <, <=, >, >=. This does not help when you just want to trace if
      a specific flag is set. For example:
       > # sudo trace-cmd record -e brcmfmac:brcmf_dbg -f 'level & 0x40000'
       > disable all
       > enable brcmfmac:brcmf_dbg
       > path = /sys/kernel/debug/tracing/events/brcmfmac/brcmf_dbg/enable
       > (level & 0x40000)
       > ^
       > parse_error: Invalid operator
      When trying to trace brcmf_dbg when level has its 1 << 18 bit set, the
      filter fails to perform.
      By allowing a binary '&' operation, this gives the user the ability to
      test a bit.
      Note, a binary '|' is not added, as it doesn't make sense as fields must
      be compared to constants (for now), and ORing a constant will always return
      Link: http://lkml.kernel.org/r/1371057385.9844.261.camel@gandalf.local.homeSuggested-by: default avatarArend van Spriel <arend@broadcom.com>
      Tested-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>