[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081203081301.GF21006@elte.hu>
Date: Wed, 3 Dec 2008 09:13:01 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Steven Rostedt <rostedt@...dmis.org>
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
* 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?
Ingo
--
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