ftrace - add support for tracing_thresh to function_graph tracer
in [Kernel]
|
Prev: [PATCH tip/core/rcu 0/21] v6 add lockdep-based diagnostics to rcu_dereference()
Next: linux-next: manual merge of the wireless tree with the wireless-current tree
From: Tim Bird on 22 Feb 2010 20:20 On 02/22/2010 10:17 AM, Frederic Weisbecker wrote: > On Mon, Feb 22, 2010 at 09:57:43AM -0500, Steven Rostedt wrote: >> On Sat, 2010-02-20 at 15:43 +0100, Frederic Weisbecker wrote: >>> >>> Instead of having yet another check here, may be should we >>> have a dedicated stub trace_graph_entry? >>> >>>> @@ -254,6 +263,10 @@ static void __trace_graph_return(struct trace_array *tr, >>>> if (unlikely(__this_cpu_read(per_cpu_var(ftrace_cpu_disabled)))) >>>> return; >>>> >>>> + if (tracing_thresh && >>>> + (trace->rettime - trace->calltime < tracing_thresh)) >>>> + return; >>>> + >>> >>> >>> >>> And perhaps we can do the same for the return handler? >>> We could have a trace_graph_return_threshold that >>> performs the above check and then relies on trace_graph_return. >> >> So you mean to register a different type of function to the graph tracer >> if trace_thresh is enabled? That does sound like a better idea. > > > Yeah, this is going to optimize both types of tracing. And I would > also like to prevent from adding new checks in the common graph > tracing if possible. User's cpus and cachelines deserve better :) I'll take a look at doing it this way, and see what I come up with. If I can re-use most of trace_graph_entry and trace_graph_return (and I don't see why not), it should be a pretty small patch. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |