This change set replaces the function tracing recursion protection
with a context one, that keeps track of interrupts, NMIs, softirqs,
such that we do not need to disable interrupts and not miss any
events, as the old recursion protection had a race where interrupt
events could be dropped.

This also speeds up function tracing by 15% or more.

I'm posting these as a generic review of the changes I'll be pushing
into linux-next and will be pushing this for 3.9.

These patches have passed a series of tests I've run on few machines
with several different configs and such.

You can find the patches here. I'll add these to linux-next tomorrow.

-- Steve

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/core

Head SHA1: 0b07436d95b5404134da4d661fd183eac863513e


Steven Rostedt (12):
      tracing: Remove trace.h header from trace_clock.c
      tracing: Fix race with max_tr and changing tracers
      tracing: Fix selftest function recursion accounting
      ftrace: Fix global function tracers that are not recursion safe
      ftrace: Fix function tracing recursion self test
      ftrace: Optimize the function tracer list loop
      ftrace: Add context level recursion bit checking
      tracing: Make the trace recursion bits into enums
      tracing: Avoid unnecessary multiple recursion checks
      ftrace: Use only the preempt version of function tracing
      ring-buffer: User context bit recursion checking
      ring-buffer: Remove trace.h from ring_buffer.c

----
 kernel/trace/ftrace.c          |   82 ++++++++++++++++---------
 kernel/trace/ring_buffer.c     |   88 ++++++++++++++++++--------
 kernel/trace/trace.c           |   29 ++++++---
 kernel/trace/trace.h           |  133 ++++++++++++++++++++++++++++++++++++----
 kernel/trace/trace_clock.c     |    2 -
 kernel/trace/trace_functions.c |   61 +++++-------------
 kernel/trace/trace_selftest.c  |   19 ++----
 7 files changed, 275 insertions(+), 139 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to