[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0812030645370.29045@gandalf.stny.rr.com>
Date: Wed, 3 Dec 2008 06:49:09 -0500 (EST)
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...e.hu>
cc: linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 4/5] ftrace: function graph return for function entry
On Wed, 3 Dec 2008, Ingo Molnar wrote:
>
> * Steven Rostedt <rostedt@...dmis.org> wrote:
>
> > From: Steven Rostedt <srostedt@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists