1. 10 Dec, 2015 3 commits
  2. 09 Dec, 2015 11 commits
  3. 08 Dec, 2015 3 commits
  4. 07 Dec, 2015 19 commits
  5. 06 Dec, 2015 4 commits
    • Andi Kleen's avatar
      perf/x86: Remove old MSR perf tracing code · f1ad4488
      Andi Kleen authored
      Now that we have generic MSR trace points we can remove the old
      hackish perf MSR read tracing code.
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.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>
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/1449018060-1742-4-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f1ad4488
    • 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>
      7f47d8cc
    • Andi Kleen's avatar
      tracepoints: Move struct tracepoint to new tracepoint-defs.h header · bd2a634d
      Andi Kleen authored
      Steven recommended open coding access to tracepoint->key to add
      trace points to headers. Unfortunately this is difficult for some
      headers (such as x86 asm/msr.h) because including tracepoint.h
      includes so many other headers that it causes include loops.
      The main problem is the include of linux/rcupdate.h, which
      pulls in a lot of other headers. The rcu header is only needed
      when actually defining trace points.
      
      Move the struct tracepoint into a separate tracepoint-defs.h
      header that can be included without pulling in all of RCU.
      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-2-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      bd2a634d
    • Andi Kleen's avatar
      x86/headers: Don't include asm/processor.h in asm/atomic.h · 153a4334
      Andi Kleen authored
      asm/atomic.h doesn't really need asm/processor.h anymore. Everything
      it uses has moved to other header files. So remove that include.
      
      processor.h is a nasty header that includes lots of
      other headers and makes it prone to include loops. Removing the
      include here makes asm/atomic.h a "leaf" header that can
      be safely included in most other headers.
      
      The only fallout is in the lib/atomic tester which relied on
      this implicit include. Give it an explicit include.
      (the include is in ifdef because the user is also in ifdef)
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.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>
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/1449018060-1742-1-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      153a4334