Messages in this thread | | | Date | Fri, 06 May 2011 11:26:24 -0400 | From | Steven Rostedt <> | Subject | [RFC][PATCH 00/13] ftrace: Allow multiple users to pick and choose functions to trace |
| |
Ingo, et. al.
This is an RFC patch set of the work I did to allow multiple users to pick and choose which functions they would like to trace without being affected by other users (well, they are still affected, but they can choose their own functions).
Since this rewrote a lot of the guts of ftrace's function handling I broke it up into steps that I can sequentially think about how to make the conversion. It also helped in understanding the changes that had to be made.
The end result now has this:
o The function record list flags item now stores a ref count, and we no longer need to have the flags if the records are filtered or set for "notrace"
o Each ftrace_ops has its own set of functions to trace or not trace which is used to update the ref counts of the function records mentioned above. If the ftrace_ops is not currently active, the records are not touched when the filters are changed. If the filters are changed while the ftrace_ops is active, it is done in a way with RCU to make the updates.
o If only one ftrace_ops is registered for tracing (actively tracing), its handler is called directly from mcount. Unless the ftrace_ops was allocated and not a static/global core kernel variable (see below).
o If more than one ftrace_ops is registered, then a function is called that will iterate over the list of registered ftrace_ops, performing a check of each of its hashes to know if ftrace_ops handler should be called for that function.
o If a ftrace_ops is allocated and not a static/global core kernel variable, it will be forced to use the function that loops through the ftrace_ops even if its the only one. This is because that function disables preemption when it performs the loop. This is needed, because dynamically allocated ftrace_ops must call synchronize_sched() before being freed (which is done when the dynamic ftrace_ops has been unregistered).
o A file has been created in the debugfs/tracing directory called enabled_functions. This file contains a list of all functions that any ftrace_ops has registered, along with each functions ref count. This can be used to make sure nothing is tracing.
I'm posting this patch series as an RFC, but I do not expect it to change much. I still have to put it through more tests even though I ran several on each set already.
-- Steve
Steven Rostedt (13): ftrace: Replace FTRACE_FL_NOTRACE flag with a hash of ignored functions ftrace: Use hash instead for FTRACE_FL_FILTER ftrace: Create a global_ops to hold the filter and notrace hashes ftrace: Separate hash allocation and assignment ftrace: Use counters to enable functions to trace ftrace: Add enabled_functions file ftrace: Add ops parameter to ftrace_startup/shutdown functions ftrace: Have global_ops store the functions that are to be traced ftrace: Free hash with call_rcu_sched() ftrace: Implement separate user function filtering ftrace: Allow dynamically allocated function tracers ftrace: Modify ftrace_set_filter/notrace to take ops ftrace: Add self-tests for multiple function trace users
---- include/linux/ftrace.h | 33 +- include/linux/kernel.h | 1 + kernel/extable.c | 8 + kernel/trace/ftrace.c | 992 ++++++++++++++++++++++++++++----- kernel/trace/trace.h | 2 + kernel/trace/trace_functions.c | 2 + kernel/trace/trace_irqsoff.c | 1 + kernel/trace/trace_sched_wakeup.c | 1 + kernel/trace/trace_selftest.c | 214 +++++++- kernel/trace/trace_selftest_dynamic.c | 6 + kernel/trace/trace_stack.c | 1 + 11 files changed, 1116 insertions(+), 145 deletions(-)
| |