[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160830221647.6a9716cc@gandalf.local.home>
Date: Tue, 30 Aug 2016 22:16:47 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH] ftrace: Access ret_stack->subtime only in the function
profiler
On Wed, 31 Aug 2016 11:11:38 +0900
Namhyung Kim <namhyung@...nel.org> wrote:
> On Tue, Aug 30, 2016 at 10:34:41AM +0900, Namhyung Kim wrote:
> > Hi Steve,
> >
> > On Mon, Aug 29, 2016 at 04:07:00PM -0400, Steven Rostedt wrote:
> > > On Mon, 29 Aug 2016 12:05:18 +0900
> > > Namhyung Kim <namhyung@...nel.org> wrote:
> > >
> > > > The subtime is used only for function profiler with function graph
> > > > tracer enabled. Move the definition of subtime under
> > > > CONFIG_FUNCTION_PROFILER to reduce the memory usage. Also move the
> > > > initialization of subtime into the graph entry callback.
> > >
> > > Hmm, I think documentation needs to be updated. Although it was never
> > > implemented, I believe I added the subtime to not only work with the
> > > profiler, but also with the normal tracing (to have the time of the
> > > internal functions subtracted from the upper level functions). But it
> > > appears that part was never implemented.
> > >
> > > I'm fine with the patch, or actually implementing what graph-time
> > > states in Documentation/ftrace.txt. If we take this patch, that comment
> > > needs to be made to only mention the profiler (and the option should
> > > only be shown when the profiler is enabled).
> >
> > Ah, missed the documentation part. To implement it in the normal
> > tracing, I think we need to add 'subtime' field to struct
> > ftrace_graph_ret which will increase disk size. Are you ok with this?
>
> On second thought, I think I can do it by just adding value of subtime
> to ftrace_graph_ret.calltime when graph-time is off. Then the
> calltime would not be the timestamp at function entry, but it seems
> not guaranteed due to the sleep-time anyway. Now I wonder why it
> doesn't have 'duration' in the ftrace_graph_ret instead of having
> calltime and rettime.
>
As it hasn't worked, like forever, I'm thinking of nuking it. Nobody
seemed to have noticed. I haven't needed to use it, and apparently
nobody else has either. Why support a feature that nobody uses?
I have used it for profiling, but not normal function graph tracing.
You can see the function times inside and do the logic post processing.
Best bet is to just update the documentation to what the current code
does.
-- Steve
Powered by blists - more mailing lists