lkml.org 
[lkml]   [2008]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/5] ftrace: function graph return for function entry

On Wed, 3 Dec 2008, Ingo Molnar wrote:

>
> * Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > From: Steven Rostedt <srostedt@redhat.com>
> >
> > Impact: feature, let entry function decide to trace or not
> >
> > This patch lets the graph tracer entry function decide if the tracing
> > should be done at the end as well. This requires all function graph
> > entry functions return 1 if it should trace, or 0 if the return should
> > not be traced.
>
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index 47aa5f0..cef05a2 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -119,6 +119,9 @@ ENTRY(mcount)
> > #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> > cmpq $ftrace_stub, ftrace_graph_return
> > jnz ftrace_graph_caller
> > +
> > + cmpq $ftrace_graph_entry_stub, ftrace_graph_entry
> > + jnz ftrace_graph_caller
>
> hm, that's in the hotpath. What's the point of this? Do we want some sort
> of configuration vector that allows per function graphing versus
> entry-only traces?

Actually, I'm fine with taking it out. But when we register a function
graph, we register both a entry and exit. I would think it should still
work if one was still set as the default. Unless we document it someplace
that either the entry or exit must be set.

This change has the function graph work if one or the other is set to
something other than the default.

Also, this is only in the static ftrace path, not dynamic, but then again,
maybe that means it is even hotter.

I'm fine with pulling this out. It was not really needed, I was just
trying to make it intuitive.

-- Steve


\
 
 \ /
  Last update: 2008-12-03 12:51    [W:0.049 / U:1.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site